Capacity math — sizing for the rush
Work out what each resource carries at the peak — servers at a target below the knee, rounded up, plus one to lose; connections; the database — and the first to run out sets the capacity. Then a load test checks the estimate.
12 minMediumStation: Capacity mathMembers lesson
Membership isn’t open yet. The free lessons are open — 16 of them.
- Connection pools
- Server capacity & scaling up
- Capacity math
- Find the bottleneck
What you'll be able to do
- 1Estimate how many servers a peak needs — the peak divided by what one server handles at a target utilization below the knee, plus enough spare to lose one.
- 2For a planned peak, work out what each resource carries — CPU, connections in use, the database's total connections — and name the one that runs out first.
- 3Choose what to size for — the peak rather than the average, a target utilization with headroom, the loss of a server — and explain why a load test has to confirm the estimate.
Inside the lesson
- steps
- 10
- questions
- 8
- simulations
- 4
You guess first, then run the system and see if you were right.
Step 1 · The setup
At the last stop, Pixel's server stayed quick until it was about 80% busy, then slowed sharply — so you plan with a buffer below that knee. Now Timetable has a plan to make.
Timetable has grown since the first stops — a new line has opened. Riders now ask for about 300 lookups a second on an average afternoon and about 600 at rush hour. The lookups pass a load balancer — one address that spreads lookups across the API servers — to Timetable's API servers, which ask the timetable database. One API server answers about 150 a second while staying under 80% busy. (In this sim the knee sits at about 80%; real servers can start to feel it from around 70%.)
Today Timetable runs 2 API servers, each about 76% busy on an average afternoon.
Steps 2–10 are for members