Redis Cache Hit Rate Calculator

Give the request rate and hit rate. The result shows what reaches the backend, at your hit rate and at several others, because that sensitivity is the thing worth planning for.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Calculate. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

A high hit rate

Where the backend sees very little, and a small drop changes that sharply

requests-per-second: 50000
hit-rate: 99
backend-latency-ms: 40

A degraded cache

The same traffic at 80%, which is four times the backend load of 95%

requests-per-second: 50000
hit-rate: 80
backend-latency-ms: 40

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Sizing the backend for the steady-state hit rate

    A restart, a flush or a mass eviction sends everything to the backend at once. The backend must survive a cold cache.

    Instead:Size for the cold case, or add a stampede guard so only one request per key repopulates.

  2. Setting the same TTL on a batch of keys

    They expire together and produce a synchronised miss spike.

    Instead:Jitter the TTLs by a random fraction.

  3. Reporting the average latency

    Hits and misses are orders of magnitude apart, so the average describes almost no real request.

    Instead:Report percentiles. The p99 is roughly the backend latency once misses exceed 1%.