Concurrency & throughput calculator (Little's Law)
Turn any two of throughput, latency and concurrency into the third. Plan how many in-flight requests your traffic implies, or what throughput a fixed concurrency can sustain.
L = λ × W. Pick which value to solve for and fill the other two — it recomputes as you type.
Little's Law
The field you're solving for is computed and locked. Edit the other two.
Concurrent users → requests per second
Active users aren't requests. Each user fires a request roughly once every think time + latency seconds.
That implies about 0 requests in flight at once (RPS × latency).
Each user issues a request roughly every (think time + latency) seconds, so RPS = users ÷ (think + latency). Implied in-flight uses Little's Law on that RPS.
The math is the easy part.
Right-sizing thread pools, connection pools, autoscaling and timeouts to the concurrency your traffic actually creates — that's the engineering. Book a free build audit and we'll load-test where your real ceiling is.
Book a Build AuditWhy concurrency, not RPS, sizes your system
Little's Law is the one formula every backend engineer should keep handy: the average number of requests in flight equals throughput multiplied by latency, concurrency = RPS × latency(s). That single relationship is why a concurrency calculator beats reasoning about requests per second alone. Throughput tells you how busy the front door is; concurrency tells you how many requests are inside the building at once — and that's what consumes threads, database connections, file handles and memory.
Two services at the same RPS can need wildly different resources. Slow down each request and more of them overlap, so the pool you need grows even though throughput hasn't changed. The table makes it concrete: hold throughput at 200 RPS and watch in-flight requests — and the connection pool you must provision — scale directly with latency. This is also why fixing latency frees capacity for free: shrink W and L shrinks with it.
| Throughput | Avg latency | In-flight (Little's Law) |
|---|---|---|
| 200 RPS | 50 ms | 10 |
| 200 RPS | 150 ms | 30 |
| 200 RPS | 500 ms | 100 |
| 200 RPS | 1,000 ms | 200 |
Little's Law assumes a stable system (arrivals ≈ departures) and average latency; bursty traffic and queueing change the picture — load-test to validate.
Questions about concurrency & throughput
How do I convert requests per second to concurrent users?
They measure different things. Requests per second is throughput; concurrent in-flight requests equal throughput times average latency (Little's Law). To go from concurrent users to RPS, divide the number of active users by the average time between their requests — think time plus request latency. This tool does both.
What is Little's Law?
Little's Law states that the average number of items in a system equals the arrival rate times the average time each spends in the system. For web services: in-flight requests = requests per second × average latency in seconds. It's the simplest reliable way to relate throughput, latency and concurrency.
Why does concurrency matter more than requests per second?
Concurrency — the number of requests in flight at once — is what consumes threads, database connections and memory. Two systems at the same RPS can need very different resources if their latencies differ: higher latency means more requests overlap, so you need more workers and connections even at the same throughput.