CDN Capacity Calculator
Estimate total requests-per-second capacity of a CDN deployment from edge node count, per-node throughput, and cache hit ratio.
Inputs
Maximum requests per second a single edge node can serve
Fraction of requests served from edge cache rather than forwarded to origin
Effective Served Capacity
460,000req/s
Raw Aggregate Edge Capacity
500,000req/s
Requests Forwarded to Origin (cache misses)
40,000req/s
Step by step
Values used
Number of Edge Nodes = 50; Per-Node Capacity = 10,000 req/s; Cache Hit Ratio = 92
Total effective CDN capacity
total_rps = edge_nodes × per_node_rps × cache_hit_ratio
Effective Served Capacity
= 460,000 req/s
Raw Aggregate Edge Capacity
= 500,000 req/s
Requests Forwarded to Origin (cache misses)
= 40,000 req/s
How it works
CDN effective capacity multiplies the number of edge nodes by each node's request-handling capacity, then applies the cache hit ratio — the fraction of requests a node can answer directly from cached content rather than forwarding to the origin. Note the cache hit ratio scales down the 'effectively served from edge' figure in this model to highlight origin offload; cache misses still get served to the end user, just at the cost of an origin round-trip, so origin capacity and origin-to-edge link bandwidth must also be sized to handle the miss traffic shown here.
Formula
Total effective CDN capacity
total_rps = edge_nodes × per_node_rps × cache_hit_ratio
- n
- Number of edge nodes
- r
- Per-node requests/sec capacity
- h
- Cache hit ratio (0-1)
Frequently Asked Questions
Why does cache hit ratio matter so much for CDN capacity?
A high cache hit ratio means most requests are answered directly from edge storage — fast and cheap — while cache misses require forwarding to the origin server, which is slower, consumes origin capacity, and uses backhaul bandwidth. A CDN with a low hit ratio effectively behaves more like a pass-through proxy than a true content cache, and origin infrastructure must be sized accordingly.
What typically causes a low cache hit ratio?
Highly dynamic or personalized content (which can't be cached the same way for every user), overly short cache TTLs, a very long tail of rarely-requested unique objects, or cache configuration mistakes (e.g. caching keyed on unnecessary query parameters that fragment the cache) are common causes worth investigating if hit ratio underperforms expectations.
How do I increase effective CDN capacity without adding nodes?
Improving cache hit ratio (longer appropriate TTLs, better cache-key normalization, pre-warming caches for predictable traffic spikes) increases effective capacity from the same edge footprint, often more cost-effectively than simply adding more edge nodes.