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
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.
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.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
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.
Where the backend sees very little, and a small drop changes that sharply
requests-per-second: 50000 hit-rate: 99 backend-latency-ms: 40
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
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
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.
They expire together and produce a synchronised miss spike.
Instead:Jitter the TTLs by a random fraction.
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%.