How to Determine If Redis Is Actually Slowing Down Using Baseline Performance

It is well known that Redis runs single‑threaded and usually responds extremely fast, but sometimes its latency spikes dramatically, causing panic among ops and developers. Before taking any action, you must first confirm whether Redis truly became slower.

Redis performance is tightly coupled with the underlying hardware and operating system, so a higher latency does not always mean Redis is at fault. The most direct way to judge is to monitor Redis response latency. In most cases latency stays low, but when command execution time jumps to seconds you can safely say Redis is slow.

The latency threshold varies by environment. For example, on a modest server (Server A) a latency of 1 s may indicate a problem, while on a well‑configured server (Server B) even 10 ms could be considered slow. Because such thresholds are hard to define, you should rely on Redis baseline performance.

Baseline performance is the system’s basic performance under low load and no interference, determined solely by the current software configuration.

Since Redis 2.8.7 the redis-cli command provides the --intrinsic-latency option, which records the maximum latency observed during a test period. The test duration can be set with the option’s argument; 120 seconds is usually sufficient.

Example command run locally (without a client) is:

redis-cli --intrinsic-latency 120

Max latency so far: 1 microseconds.
Max latency so far: 9 microseconds.
Max latency so far: 11 microseconds.
Max latency so far: 29 microseconds.
Max latency so far: 34 microseconds.
Max latency so far: 36 microseconds.
Max latency so far: 42 microseconds.
Max latency so far: 44 microseconds.
Max latency so far: 62 microseconds.
Max latency so far: 599 microseconds.
Max latency so far: 613 microseconds.
Max latency so far: 8158 microseconds.
Max latency so far: 13426 microseconds.
Max latency so far: 16073 microseconds.
Max latency so far: 19587 microseconds.
Max latency so far: 22988 microseconds.

1982697419 total runs (avg latency: 0.0605 microseconds / 605.24 nanoseconds per run).
Worst run took 379819x longer than the average latency.

The highest observed latency, 22988 µs, becomes the baseline latency for this machine. Baseline performance depends only on OS and hardware, so you can compare current latency against it. Generally, if the runtime latency exceeds twice the baseline, Redis can be considered slow.

If the observed latency is more than 2× the baseline, you can conclude that Redis is slow.

Note that baseline performance is especially important in virtualized environments (VMs, containers) where the baseline can be high; therefore, using the baseline for judgment is essential.

Also, always run the test on the target machine itself. If you run it through a client, network performance may affect the results. Tools like iperf can help you detect network bottlenecks, after which you should involve network engineers.

In summary, the article describes how to use Redis baseline performance and latency measurements to decide whether Redis has truly slowed down, with a rule of roughly double the baseline indicating a slowdown.