Added cache for COMMAND

[ebarskiy]

COMMAND command is expensive to process (too much string operations)
but result is rarely changes, it makes sense to add caching

[JimB123]

What evidence is there to suggest that COMMAND

is expensive to process (too much string operations)

How meaningful is the benefit of caching this information? I can't tell if this represents premature optimization (adding complexity without sufficient value).

[JimB123]

This should be a common function associated with a cached response client. It's unclear why this is different from aggregateClientOutputBuffer and I tagged @roshkhatri for info.

[ebarskiy]

aggregateClientOutputBuffer assumes c->bufpos == 0 which is not the case here as Add* functions utilize c->buf

[JimB123]

FYI - I talked with @roshkhatri. He agrees that the existing function aggregateClientOutputBuffer should be updated rather than creating a new function. His existing function assumed c->bufpos == 0 for his specific use case, but this does not have to be generally true. We can update that function.

[JimB123]

Just move cacheCommandInfo after addReplyCommandInfo, avoiding the need for a forward declaration.

[ebarskiy]

there is a recursion to process subcommands

[ebarskiy]

What evidence is there to suggest that COMMAND

is expensive to process (too much string operations)

How meaningful is the benefit of caching this information? I can't tell if this represents premature optimization (adding complexity without sufficient value).

@PingXie can you share internal latency of COMMAND?

[hpatro]

Have a similar question in the lines of @JimB123 requested.

Why do we want to optimize this particular command? This is not a heavily used command AFAIK. Apart from the clients invoking it upfront to build certain metadata. Does this lead to tail latency on your end for datapath commands?

[hpatro]

Would recommend building an array similar to cached_cluster_slot_info.