Web Concurrency, QPS and Latency: Estimate Capacity Carefully
Content edited . This editorial update does not represent a new runtime test.
On this page
Web concurrency is the amount of work in flight; QPS is requests processed per second. They are not interchangeable. Daily page views alone cannot tell you how much concurrency a service must support, because request patterns and response times matter.
Keep the units explicit
| Metric | Meaning |
|---|---|
| QPS | Requests per second at the measured boundary. |
| TPS | Transactions per second; define what constitutes a transaction. |
| In-flight requests | Requests started but not yet completed. |
| Latency | Time a request takes; inspect percentiles as well as averages. |
| Page views | A browsing measure that may generate several backend requests per view. |
For a stable system, a useful approximation is average in-flight requests = request rate × average response time. With 100 requests/second and 0.2 seconds per request, the average is about 20 in flight. This is an estimate, not a promise about peak queues or tail latency.
Revisit the original traffic example
The 2018 note assumed 80% of daily traffic arrived during 20% of a day. With 3,000,000 daily requests under that assumption:
busy-period average QPS = 3,000,000 × 0.8 / (86,400 × 0.2)
≈ 138.9 requests/second
This is the average during the assumed busy period, not a measured instantaneous peak. If a server sustains 90 QPS for the same workload, dividing and rounding up gives two servers before accounting for redundancy, headroom or shared bottlenecks. The 90-QPS capacity itself must come from measurement.
The original screenshot was a third-party anecdote. It does not establish capacity for your hardware or permit extrapolating another service’s daily traffic.
Validate before sizing production
Define request mix, response size, database dependencies and cache state. Increase load in stages and observe latency percentiles, errors, CPU, memory and queues. A throughput number that only works while latency rises without bound is not sustainable capacity.
Optimize the actual bottleneck: avoid unnecessary queries, measure cache effectiveness and use load balancing where appropriate. More app servers cannot necessarily fix a saturated database. No load test was run for this article’s hypothetical numbers during this revision.
Related: Programming concurrency and parallelism explain execution models rather than service traffic.