Calculator
This page uses a single-column page flow. The calculator inputs become three columns on large screens, two on tablets, and one on mobile.
Example data table
Example outputs assume stale hits are counted as hits, bypass requests are included, and backend errors are excluded from the hit-rate denominator.
| Scenario | Hits | Misses | Stale | Bypass | Errors | Hit Rate | Avg Latency | Offload |
|---|---|---|---|---|---|---|---|---|
| API edge cache | 84,000 | 12,000 | 2,000 | 1,000 | 300 | 86.87% | 21.02 ms | 86.61% |
| Search index cache | 48,500 | 10,400 | 1,100 | 2,500 | 120 | 79.36% | 37.60 ms | 79.21% |
| Product page cache | 120,000 | 15,000 | 6,000 | 800 | 40 | 88.86% | 21.93 ms | 88.83% |
Formula used
Core hit-rate formula
Cache Hit Rate (%) = (Counted Hits ÷ Adjusted Request Base) × 100
Counted Hits = Cache Hits + Optional Stale Hits
Adjusted Request Base = Hits + Misses + Stale Hits + Optional Bypass + Optional Errors
Latency and offload formulas
Average Latency = Weighted Latency Sum ÷ Observed Requests
Latency Saved = (Miss Latency − Average Latency) × Observed Requests
Cache Offload (%) = Cache-Served Requests ÷ Observed Requests × 100
This calculator also estimates backend bandwidth offload by multiplying cache-served requests by the average object size.
How to use this calculator
- Enter the time window name, such as hourly, daily, or release traffic.
- Fill in hits, misses, stale hits, bypass requests, and backend errors.
- Enter average latencies for hit, stale, miss, and bypass paths.
- Choose whether stale hits, bypasses, and errors affect the denominator.
- Set a target hit rate, then click Calculate.
- Review summary metrics, charts, and export the result as CSV or PDF.
FAQs
1. What counts as a cache hit?
A cache hit happens when the requested object is served directly from cache without fetching a fresh backend copy. This usually lowers latency and reduces backend work.
2. Should stale hits be counted as hits?
Count stale hits as hits when your system intentionally serves stale data during revalidation or failure modes. Leave them separate when freshness matters more than speed.
3. Why would bypass requests be included in the denominator?
Include bypass traffic when it represents real user demand that avoided cache. Exclude it when bypasses are operational exceptions and should not distort normal cache efficiency.
4. What is a good cache hit-rate target?
A good target depends on workload type. Static assets often exceed 95%, while dynamic API caching may be lower. Benchmark against your latency and origin-cost goals.
5. Why can hit rate improve while latency still looks bad?
A higher hit rate does not guarantee better user experience. Large misses, slow bypasses, backend contention, or stale revalidation delays can still keep average latency elevated.
6. Can this calculator work for CDN, Redis, or application caches?
Yes. The inputs are generic enough for CDN caches, in-memory stores, database query caches, object caches, and edge delivery layers.
7. Which time window should I analyze?
Use multiple windows. Compare peak traffic, daily averages, and release periods. A single aggregated number can hide bursts, cold starts, and invalidation effects.
8. Why are backend errors optional in hit-rate calculations?
Some teams treat errors as demand that cache failed to absorb. Others track them separately because they reflect origin instability rather than caching quality alone.