Card 03/ 08
Sizing Capacity for the Average Instead of the Peak
The average is a number no hour of the day ever has.
Capacity has to be sized for the peak, plus one spare server, not for the average. The average is a number most hours of the day are above or below, so a system sized for it is idle at night and overloaded every evening.
The symptom. The news site runs well all day. Every evening at nine, pages slow down, some requests fail, and the next morning everything is fine again. The dashboards show the servers were "at capacity", and the estimate said they would never be.
The trigger. The estimate stopped at the average, 1,736 requests a second, and the team ran one server rated at 2,000. That looks like headroom. The illustrative day below shows why it is not.
| Hour | Requests a second | Against one server at 2,000 |
|---|---|---|
| 04:00 | 300 | Mostly idle |
| 08:00 | 2,600 | Overloaded |
| 13:00 | 2,200 | Overloaded |
| 17:00 | 1,700 | Near the limit |
| 21:00 | 5,200 | More than twice its capacity |
The mechanism. The average is low because the night is nearly empty. Users do not arrive at the average; they arrive in the morning and the evening. A server past its capacity does not slow down politely: requests queue, wait times climb, and clients give up and retry, which adds more load.
The cost. The site fails at the hour most people use it, which is the hour that matters most to the business.
The remedy. Size for the peak: 5,200 ÷ 2,000 rounds up to three servers. Then add one, so that a single server failing at nine in the evening leaves enough capacity to carry the peak. That spare is often written N+1: the N servers the load needs, plus one.
- System Design
- Performance
- Fault Tolerance
← → move through sections and cards