Before blaming Redis for a slow endpoint, how would you measure an individual Redis server's own response latency and its floor on that machine, using tools shipped with Redis?

## Why measure before blaming "Redis is slow" is almost always reported from the application's stopwatch, which contains connection pool waits, client-library serialization, TLS, network, and the server. Ruling layers out in order is faster than guessing. Redis ships tools for exactly this and they need no agent, no APM, and no restart. ## Round-trip latency: `redis-cli --latency` ``` redis-cli -h redis-prod-1 --latency min: 0, max: 6, avg: 0.28 (1284 samples) ``` It sends `PING` as fast as it can and reports **min / max / avg round-trip in milliseconds** with a sample count, updating live. `PING` costs the server essentially nothing, so whatever you see is the cost of *everything except the work*: client scheduling, the network path, the server's event loop availability, and time queued behind other clients' commands. Interpretation: - avg well under 1ms with a low max — the path is healthy; the slowness is in your application or in specific expensive commands. - low avg but a large max — **spikes**, not a slow baseline. That points at blocking commands, fork during a save, or an expire burst. Switch to `--latency-history` (prints a summary line every 15 seconds by default; `-i` changes the interval) to see whether spikes are periodic, which is a strong hint of a background save or a cron-driven job. - high avg overall — either the network path (run it from a second host to compare) or the machine itself. Run it **from a machine that resembles your application hosts**. Running it on the Redis box hides all network cost; running it from a laptop over VPN measures your VPN. `redis-cli --latency-dist` renders the distribution as a colour spectrum, which makes a bimodal "mostly 0.2ms, sometimes 40ms" pattern obvious in a way an average never will. ## The floor: `redis-cli --intrinsic-latency` ``` redis-cli --intrinsic-latency 100 Max latency so far: 3 microseconds. ... Max latency so far: 1200 microseconds. ``` This mode is different in kind. It connects to nothing and executes no Redis command: it runs a tight loop for the given number of seconds, repeatedly reading the clock, and reports the largest gap it ever observed between two consecutive reads. That gap is the time the operating system took the CPU away — scheduler preemption, hypervisor steal time, page faults, transparent-huge-page compaction, SMIs. Because it measures the host, it **must be run on the Redis server itself** (it is safe: it burns one core for the duration, so run it briefly and be aware of that). The result is the hard floor: a single-threaded process cannot respond faster than the OS lets it run. If intrinsic latency is 4ms, then a p99 of 5ms from clients is not a Redis problem at all — it is a noisy or oversubscribed host, and the fix is a different instance type, CPU pinning, disabling transparent huge pages, or moving off a burstable/throttled vCPU. ## Filling in the middle: `INFO commandstats` and `INFO latencystats` `INFO commandstats` gives, per command: `calls`, `usec` (total microseconds), `usec_per_call`, plus rejected/failed counts. This answers "is one command mildly slow a million times a second?" — a case SLOWLOG never shows because no individual call crosses the threshold. Redis 7.0 adds `INFO latencystats`, which reports per-command latency **percentiles** from a histogram, so you can see p50/p99 per command rather than only an average. `CONFIG RESETSTAT` zeroes these counters so you can measure a clean window. ## A workable order of operations 1. Confirm the symptom from the client's own metrics (p99, not average). 2. `redis-cli --latency` from an app-like host — is the baseline itself bad, or is it spiky? 3. `redis-cli --intrinsic-latency 60` on the server — is the machine's floor already at that level? 4. `SLOWLOG GET` — is a single blocking command causing the spikes? 5. `INFO commandstats` / `latencystats` — is a frequent command mildly expensive? 6. `INFO clients` (`blocked_clients`, `client_recent_max_input_buffer`) and `INFO stats` — is the problem connection churn, a huge pipeline, or output-buffer pressure? Each step either exonerates a layer or names the offender, which is exactly what an interviewer wants to hear instead of "I'd add more memory".