[jnewland]

Those tools are certainly useful! In the recent production incident I mentioned, we we able to quickly use SLOWLOG to determine which calls were causing the latency spikes. Thanks deeply for providing all of these useful tools and docs.

> there is a percentage of users that will not read the doc and just deploy it

I wonder what this percentage is? I'd wager that it is higher than you might have anticipated, especially given the other comments on this thread.

As an engineer on a team ultimately responsible for the availability of a production service, it's my responsibility to ensure that the percentage of engineers that know the latency side effects of any Redis calls they make is near 100%. In the presence of such variable latency, any means of making that variability more obvious to all users of Redis would be a positive step towards happy users and operators.

[antirez]

I understand your point of view. Unfortunately I think Redis in this regard is a tool where to help is hard: I try to provide documentation but is the kind of tool that looks superficially so easy to use, yet you need some understanding in order to really use it effectively and deploy it safely. It's part of the fact that uses 1) uncommon tradeoffs and 2) is a set of commands without a predefined use-case, so there is tons to invent in the good and bad side :-)