How to Design System Capacity: From QPS Calculation to Scaling Strategies

Background

Every year the organization holds a sports meet with a 2000 m race. Typically 40 men and 20 women register, and only one rubber track is available. Ten participants run per race, requiring at least six rounds. Each round lasts 30 minutes (20 minutes race time plus preparation and cleanup).

When the 4000 m race was cancelled this year, the 2000 m registration increased by 50 people, causing capacity problems and forcing half of the participants to race the following weekend.

Concept

What is capacity design? It is the process of estimating system capacity using concrete metrics such as data volume, concurrency, bandwidth, registered users, active users, online users, message size, image size, storage, CPU, and memory.

We will use concurrency as an example to illustrate the analysis.

Analysis Process

Understanding Key Metrics

TPS (Transactions Per Second) : number of transactions per second.

QPS (Queries Per Second) : number of requests per second, a common throughput metric.

Concurrency : number of simultaneous requests the system can handle.

Peak QPS Calculation

1. Principle: 80% of traffic occurs in 20% of the time (peak period).

2. Formula: (Total PV × 80%) / (Seconds per day × 20%) = Peak QPS.

PV (Page View) : page visits.

UV (Unique Visitor) : distinct visitors per day.

Throughput : number of requests processed per unit time.

Response Time (RT) : average time to respond to a request.

Relationships:

QPS = Concurrency / Average Response Time

Concurrency = QPS × Average Response Time

When to Evaluate System Capacity

1. Temporary traffic spikes (e.g., 618, Double 11, holiday promotions).

2. Initial system capacity assessment before launch.

3. Changes in capacity baseline due to feature growth, data increase, or rising active users.

Evaluation Steps

1. Analyze Daily Total Visits

Collect real traffic data from the system or estimate PV/UV for new projects.

2. Estimate Average Daily QPS

Divide total daily visits by the number of active seconds (e.g., 11 hours ≈ 40 000 seconds).

3. Estimate Peak QPS

Use traffic curves or the 80/20 rule to calculate peak QPS.

4. Performance Stress Test

Run load tests (e.g., nGrinder, JMeter) to find the maximum QPS a single instance can sustain before response time exceeds 2 seconds.

5. Confirm with Redundancy

Based on the peak QPS and per‑instance limit, determine the required number of instances (e.g., peak = 7500 QPS, per‑instance = 2000 QPS → at least 4 instances).

Other dimensions such as data volume, bandwidth, CPU, memory, and disk follow similar estimation methods.

Case Study: Book Reservation System

Using the 80/20 rule, the system operates for 9 hours (32 400 seconds). With 1 500 000 total PV:

Peak QPS = (1 500 000 × 80%) / (32 400 × 20%) ≈ 185 QPS.

Concurrency = 185 QPS × 0.5 s ≈ 92.5 → rounded to 100.

Applying a pessimism/normal/optimism factor yields a recommended concurrency of 200.

Performance testing showed a single Tomcat instance supports up to 2500 QPS; after safety margin, the target is 2000 QPS, requiring at least four web instances.

Summary

System capacity evaluation should be performed in three scenarios: temporary traffic spikes, initial launch, and baseline growth. The steps are:

Analyze daily total visits.

Estimate average QPS.

Estimate peak QPS (traffic curve or 80/20 rule).

Conduct performance stress testing.

Adjust based on redundancy and actual results.

Applying these steps to the sports‑event example would have prevented the scheduling issues caused by the unexpected increase in participants.

Author: Weng Zhihua Source: cnblogs.com/wzh2010/p/14454954.html