Example 1
- 950 hits
- 50 misses
95.0%
What cache hit ratio at 950 and 50? 95.0%. Requests, not byte-hit.
Cache Hit Ratio Calculator
Type hits and misses. 950 and 50 give 95.0%. 800 and 200 give 80.0%. 99 and 1 give 99.0%. This is a request hit ratio, not a byte share.
This is request counts: hits / (hits + misses). Not byte-hit and not GB volume. Call cost sits on cost per request.
Results
Enter data and click Calculate.
How it works
Cache hit ratio in this calculator is a request count. 950 hits and 50 misses give 95.0%. 800 and 200 give 80.0%. 99 and 1 give 99.0%. The formula is hits / (hits + misses) × 100. This is not a byte-hit ratio and not the share of gigabytes served from cache.
A hit is a request served from cache. A miss is a request that went farther. 95.0% at 950 and 50 means 50 of 1000 requests skip cache. The calculator does not weigh responses in bytes. A large miss and a small hit count the same.
Both numbers must come from the same window. Hits from a day and misses from an hour break the ratio. A CDN layer and Redis are two separate hit ratios. Here you type one pair.
Cost per request next door multiplies a price per million by a call count. Here only the percentage stays. 95.0% is not an invoice. 80.0% at 800 and 200 is still 200 requests outside cache.
Type 950 and 50, then Calculate. The result is 95.0%. A comma in 950,5 works. Zero in both fields gives no ratio, because there is no divide by zero.
950 and 50 give 95.0%. 800 and 200 give 80.0%. 99 and 1 give 99.0%. A different request pair gives a different hit ratio.
Formula
hit ratio = hits / (hits + misses) × 100
How to use
- Type 950 hits and 50 misses.
- Click Calculate. The hit ratio is 95.0%.
- 800 and 200 give 80.0%. 99 and 1 give 99.0%.
- This is request counts, not byte-hit.
- The next card prices those calls. It does not compute a ratio.
950 and 50 give 95.0%
Hit ratio = hits / (hits + misses). 950 and 50 give 95.0%. Requests, not byte-hit.
- Cache
- The layer you count requests on. 950 and 50 give 95.0%. Not GB.
- Hit
- A request from cache. 99 and 1 give 99.0%. Not a byte share.
- Ratio
- A share of requests. 800 and 200 give 80.0%. Not byte-hit.
Examples
Example 2
- 800 hits
- 200 misses
80.0%
What hit ratio at 800 and 200? 80.0%. 200 requests miss cache.
Example 3
- 99 hits
- 1 miss
99.0%
What hit ratio at 99 and 1? 99.0%. Still a request count.
Related calculators
Common questions
What cache hit ratio at 950 and 50?
95.0%. 950 / 1000 requests. This is not byte-hit.
What about 800 and 200?
80.0%. 200 of 1000 requests leave cache.
What about 99 and 1?
99.0%. 99 / 100 requests. Still a request count.
Is this a byte-hit ratio?
No. The calculator counts requests. A large response and a small one count the same.
Is 95.0% the GB served from cache?
No. It is a share of requests. Byte volume is outside this calculator.
Can I mix CDN and Redis?
Not in one entry. One pair, one layer, one window.
What if both fields are zero?
There is no ratio, because we do not divide by zero. Type at least one request.
Does a comma in 950,5 work?
Yes. 950,5 and 50 give a different hit ratio than 950 and 50.
How is this different from cost per request?
That card is price / 1e6 × count. Here 950 and 50 stay 95.0%.
Knowledge sources
The calculator counts bits, bytes or throughput from your numbers. Below are SI and bit definitions (NIST).
Page updated in 2026.
What cache hit ratio measures
Cache hit ratio is the share of requests served from cache without falling through to a slower origin (database, disk, API, or CDN origin). A hit means the response came from cache; a miss means data had to be fetched or recomputed. Always measure it over a defined time window — the last hour, day, or the period between deploys.
Why hits and misses must share the same window
The ratio only makes sense when both counts come from the same period and the same cache layer. Hits from a day and misses from an hour produce a false picture. Likewise: mixing CDN edge metrics with Redis, or summing several clusters without a clear definition of “request.”
- Use the same time label in Prometheus / your CDN dashboard.
- After a cache restart (cold start), hit ratio drops temporarily — that is not necessarily a config regression.
- Compare like with like: same endpoint, region, and content type.
Offload, latency, and origin cost
Every miss adds latency and origin load. At 90% hit ratio the backend still handles 10% of traffic; at 99%, only 1%. Moving from 90% to 99% is therefore a 10× cut in origin calls — not “just 9 percentage points.”
- Offload — fewer origin requests means less CPU, I/O, and egress spend.
- Latency — a memory/edge hit is usually orders of magnitude faster than a miss.
- Cost — with a paid origin (API, managed DB), every miss-rate point has a real price.
TTL, capacity, eviction, and keys
- TTL — a longer TTL usually raises hit ratio but increases stale-data risk; a shorter TTL keeps data fresher at the cost of more misses.
- Capacity — a cache that is too small evicts hot keys before they can be reused.
- Eviction (LRU/LFU) — a bad policy or a storm of unique keys can tank hit ratio even with a “large” RAM limit.
- Key design — overly specific keys (e.g. unused query params) fragment traffic and kill shared hits.
Layers: CDN, app, database, browser
- CDN / edge — often targets 95–99%+ for static assets; high hit ratio means less origin traffic.
- Application cache (Redis, Memcached) — typically 70–90% for dynamic data.
- DB query cache — helps repeated reads; it does not replace indexes.
- Browser cache — local to the user; invisible in server-side metrics.
Examples
- 900 hits, 100 misses → hit ratio 90%, miss rate 10%, 1,000 requests. The backend still serves every 10th request.
- Low 40% ratio (400 hits, 600 misses) — common causes: undersized cache, TTL too short, keys with session-id / unused params, cold start after deploy.
- Before / after: 600/400 (60%) → after longer TTL and cleaner keys 950/50 (95%). Origin load falls from 40% to 5% of traffic.