Hong Life CalculatorsUnderstanding the server capacity planning calculator — concept and principle
Capacity planning answers a practical question: how many servers (or containers, or instances) do you need so that peak traffic is served comfortably, and the service survives losing a machine? This calculator combines peak load, measured per-server capacity, a headroom percentage and an N+x redundancy count into a whole number of servers.
How it is calculated
Servers = ⌈peak ÷ (per-server capacity × (1 − headroom ÷ 100))⌉ + x
- Peak requests/s: the highest sustained load you expect, not the daily average.
- Per-server capacity: requests/s one server handles while still meeting your latency target, ideally measured by a load test.
- Headroom: the share of each server you keep unused for bursts and slow periods; 30% means planning to run each server at no more than 70%.
- N+x: extra servers so the remaining N still carry the peak after x failures or during maintenance.
- ⌈ ⌉ means rounding up, because you cannot deploy part of a server.
The principle
Running servers close to 100% utilisation is risky: queueing theory shows that waiting time rises steeply as utilisation approaches full load, so small bursts cause large latency spikes. Headroom keeps each machine in the comfortable range. Rounding up guarantees the target is met rather than missed by a fraction. Redundancy is added after rounding because spares must be complete machines able to take over the whole share of a failed one.
Worked example
- Inputs: peak 2,000 requests/s, 300 requests/s per server, 30% headroom, N+1.
- Usable capacity per server: 300 × (1 − 0.30) = 210 requests/s.
- Base servers: 2,000 ÷ 210 = 9.52, rounded up to 10.
- Add redundancy: 10 + 1 = 11 servers.
| Requests/s one server handles | Servers needed |
|---|---|
| 75 | 40 |
| 150 | 21 |
| 225 | 14 |
| 300 | 11 |
| 375 | 9 |
| 450 | 8 |
| 600 | 6 |
How to read the result
With 11 servers sharing 2,000 requests/s, each runs at about 182 requests/s, roughly 61% of its tested capacity. If one fails, the other ten carry about 200 requests/s each, still below the 210 limit. Re-run the calculation whenever traffic forecasts, code performance or instance types change, and compare cost of extra servers with the cost of an outage.
Common mistakes
- Using average traffic instead of peak traffic.
- Taking per-server capacity from a vendor benchmark instead of your own workload.
- Forgetting shared bottlenecks such as the database, cache or load balancer.
- Placing all N+x servers in one rack or zone, so a single event removes several at once.
Frequently asked questions
How much headroom should I keep?
It depends on how spiky traffic is and how fast you can add capacity. Teams with fast autoscaling can run hotter than teams that buy hardware months ahead.
Is N+1 enough?
For small clusters it is common. Larger fleets, or those spread across zones, often plan for N+2 or for losing a whole zone.
Does autoscaling remove the need for this?
No. You still need a minimum size, a maximum, and enough capacity to absorb load while new instances start.
Sources: J. D. C. Little, A Proof for the Queuing Formula: L = λW, Operations Research 9(3), 1961 · B. Beyer et al. (eds.), Site Reliability Engineering, O'Reilly Media, 2016