Capacity Estimator
How many servers do you actually need? Answer with arithmetic instead of vibes: give the estimator your request rate, the CPU time each request burns and the response time users see, and it returns the cores the traffic keeps busy, the whole servers to provision — with your redundancy policy applied — the concurrency your connection pools must survive, and what the same service looks like at two, five and ten times the traffic.
- Required cores
- Servers for the traffic
- With redundancy
- Requests in flight (Little's law)
- Estimated egress
Growth table
| Traffic | Requests/s | Cores needed | Servers (with redundancy) |
|---|
The formulas, in plain language
Cores. Multiply the request rate by the CPU seconds each request consumes: that is how many cores the traffic keeps busy at 100%. Then divide by your target utilisation — at 70%, every core you provision only counts as 0.7 of a core of plan, and the other 0.3 is the headroom that keeps queues short when traffic wobbles. Cores needed = requests/s × CPU seconds per request ÷ target utilisation.
Servers. Divide cores by cores per server and round up — there is no such thing as 0.4 of a server, and rounding down is how a plan that works on average fails at the peak. Redundancy is applied after: N+1 adds one spare server to the rounded count; 2N doubles the whole fleet. Concurrency is a separate number from Little's law: requests in flight = requests/s × response time in seconds. It sizes thread pools, database connections and file descriptors — the limits services actually hit while their CPUs are still loafing. Egress, when you give a response size, is requests/s × size × 8, the bits your network bill is made of. The companion article, how many servers do you actually need, explains where each input comes from and why vendor benchmarks disagree with all of this.
Planning siblings: the SLA error budget calculator turns the availability target this capacity defends into minutes, and the backup retention calculator sizes the storage side of the same system.
Frequently asked questions
Why plan for 70% utilisation instead of 100%?
Because queues explode before saturation, not at it. A CPU that is 95% busy on average is a CPU whose queue grows without bound every time traffic wobbles — and traffic always wobbles. The utilisation target is the headroom that absorbs peaks, deploys, retries and one slow dependency. Seventy percent is the industry default for latency-sensitive services; batch workers that tolerate delay can run hotter, and anything user-facing and spiky should run cooler.
What is the difference between cores and in-flight requests?
They answer different questions. Cores come from CPU service time: how much processor each request consumes. In-flight requests come from Little’s law: rate multiplied by response time, and they measure concurrency — connections, threads, memory held open — not processor load. A service with slow downstream calls can hold 500 requests in flight while using two cores, and it will run out of connection pool long before it runs out of CPU. Size both, or the one you ignored becomes the outage.
My load test says one server handles 2,000 requests per second. Why does this estimator disagree?
Load tests usually measure a warm, steady, cache-hot service answering one request shape from a generous client. Production adds cold starts, TLS handshakes, retries, a long tail of slow requests, noisy neighbours and the deploy that halves capacity for ten minutes. The estimator is deliberately conservative — average CPU time, a utilisation ceiling, whole servers, redundancy added. Treat the load test as the ceiling of what is possible and this number as the floor of what to provision; the truth for planning is the floor.
What does N+1 actually protect against?
One failure: a dead host, a bad deploy pulled from rotation, an availability zone event that takes a single instance. With N+1, the remaining N servers still meet the target — that is the point of sizing N from the traffic first and adding the spare after. 2N is a different promise: two full copies, usually across regions, for services that must survive losing an entire copy. It doubles the bill, so it is bought for the services whose absence is measured in headlines.
How do I get my CPU service time per request?
Measure it, do not guess it. On a running service: total CPU seconds consumed over a window, divided by requests served in the same window. Application performance monitoring tools report it directly as CPU per request; on Linux you can derive it from process CPU time in /proc or your container metrics. Use the number from your busiest realistic hour, not the all-day average — capacity planned from averages fails precisely at the peak it was bought for.