client_longest_output_list

[Kevin Johnson]

Hello All,

I haven't seen much documentation on the interwebs regarding the client metric "client_longest_output_list".  

What does this metric actually measure and is it useful for indicating cluster / client health?

Thanks!

Kevin

[hva...@gmail.com]

Here's a snippet from the documentation page for the INFO command (https://redis.io/commands/INFO):

Here is the meaning of all fields in the clients section:

• connected_clients: Number of client connections (excluding connections from slaves)
• client_longest_output_list: longest output list among current client connections
• client_biggest_input_buf: biggest input buffer among current client connections
• blocked_clients: Number of clients pending on a blocking call (BLPOP, BRPOP, BRPOPLPUSH)

There doesn't seem to be a definition on that page of the meaning of "output list", but from context I'm pretty sure it means the data buffered to be sent to a client.  (like the third bullet point, but in the other direction)

[Kevin Johnson]

Thanks for the reply. So i'm guessing it's the buffered results of a client command that, due to some low-level system bottleneck, is prevented from being immediately returned...?

[hva...@gmail.com]

Yes.  Clients can invoke SUBSCRIBE/PSUBSCRIBE or MONITOR commands to start receiving a stream of data, or HGETALL or KEYS to get a potentially long list of keys/values, or even a single GET of a very large key, which can buffer a bunch of data.  If, as you said, the network path to the client goes on the blink, Redis can have data buffered for a while without seeing a disconnect event.  And INFO can reveal the connection that might be a problem.

[Kevin Johnson]

ok - so this metric more likely indicates issues with kernel/hw/network health rather than with the health of the Redis server itself...

[hva...@gmail.com]

Yes, most often it's a problem on the client end making it slow to swallow data, or impairments in the network between the server and the client preventing data from flowing quickly to the client.  In most situations, transmitting data takes fewer server resources than receiving it, so when a backlog accumulates on the sending end, it points toward trouble on the receiving end or in between.

[Kevin Johnson]

Thanks for you advice!