Capacity & Load Testing

How much can this system take, how much headroom is left, and which load-test shape answers the question you actually have? Everything here is arithmetic on your assumptions — label it that way when you present it.

Capacity planner

ESTIMATEDArithmetic on your assumptions, not a prediction.

Every output below is derived from the inputs you set. It assumes work distributes evenly, that per-request cost stays constant as load rises (it does not — contention grows), and that CPU is the binding constraint. Use it to size a starting point and to notice when an assumption is absurd, then validate with a load test.

Average traffic800 req/sTake this from production, not from a projection. Use the busiest representative hour, not the daily mean.Peak multiplier3 ×Peak divided by average. Retail and events push this far higher than most teams expect; measure it from a real peak.CPU per request12 msCPU time, not wall-clock latency. A request that waits 200 ms on a database may burn only 5 ms of CPU.Mean latency120 msUsed with Little's Law to derive concurrency, which is what sizes pools and thread counts.Cores per instance4 coresUsable cores, after whatever the sidecars and the runtime take.Target CPU utilisation60 %The headroom decision. Above roughly 70–80% the queueing curve gets steep, so this is where you buy tail latency.Memory per in-flight request2 MBPeak working set per concurrent request, not resident size at idle.Storage growth20 GB/dayIncluding indexes, replicas and retention — the number that decides next year's bill.

peak traffic

2,400 req/s

instances needed

requests in flight

288

memory at peak

0.6 GB

CPU demand

28.8 cores

storage / year

7.1 TB

What this is telling you

• At 60% target utilisation you are buying 40% headroom. That is a defensible middle: enough slack to absorb a spike without paying for double the fleet.
• 288 concurrent requests is the number every pool, thread count and connection limit on this path must exceed. If your database pool is smaller than this, the pool is your real capacity limit, not the CPU.
• This sizes for a peak of 3× average. Measure that multiplier from a real peak — teams routinely under-estimate it, and the cost of being wrong is asymmetric.
• Instances are sized on CPU alone. If the service is I/O-bound, CPU will never be the constraint and this number is meaningless — size on concurrency instead.

Lesson: Capacity Planning: Traffic to Machines →Lesson: Headroom: The Capacity You Deliberately Do Not Use →Lesson: Little's Law as Working Intuition →

Load-test shapes

Each shape answers a different question, and each is blind to what the others find.

Increase load in steps and hold each step long enough to reach steady state. 100 → 500 → 1k → 5k → 10k req/s.

What it answers

Where the knee is: the load at which latency stops being flat and starts climbing. This is the number capacity planning actually needs.

What it will not find

Anything that only appears over hours (leaks, disk fill, cache drift) and anything caused by a sudden change rather than a level.

Lesson: Load Test Shapes: The Shape Is the Hypothesis →