Enter any two of throughput, latency and concurrency and get the third. Then see how many workers or connections you need to carry that load with headroom.
Runs entirely in your browser — nothing you enter here is sent to a server.
L = λ × W. The average number of items in a system (L) equals the rate at which they arrive (λ) multiplied by the average time each one spends there (W). For a web service: concurrent requests = requests per second × response time in seconds. At 400 requests per second and 120 ms each, 48 requests are in flight at any moment.
The law is remarkable for what it does not need. It holds for any arrival pattern, any distribution of service times and any scheduling order, as long as the system is stable — work is leaving as fast as it arrives. That makes it one of the few pieces of queueing theory you can use with nothing but two numbers from a dashboard.
Concurrency is the number of workers busy on average. Divide by your target utilisation to leave room for bursts.
Queries per second × average query time = connections in use. If that is near the pool size, requests are waiting for a connection.
Turn it round: workers ÷ latency = the most requests per second the service can complete.
If the tool reports concurrency, throughput and latency that do not satisfy the equation, the test or the measurement is wrong.
Little's Law gives averages, and traffic is not average. Arrivals bunch together, some requests are slow, and as utilisation approaches 100% the queue — and therefore the latency — grows without limit. A system planned for exactly the average concurrency is saturated half the time. Running pools at 60–70% of their size is the usual compromise: the "workers needed" figure above already includes it.
A theorem from queueing theory: the average number of items in a stable system equals the average arrival rate multiplied by the average time an item spends in the system, L = λW.
Multiply peak requests per second by the average response time in seconds to get the concurrency, then divide by your target utilisation — for example 0.7 — to add headroom.
Yes, for long-run averages; it makes no assumption about the arrival pattern. It does not tell you how bad the peaks are, which is why you add headroom.
Concurrency is throughput times latency. When latency rises and traffic stays the same, concurrency rises in proportion until the pool is full; after that, requests queue and time out.
Upzilla checks your sites, servers and APIs around the clock and alerts you the moment something breaks. 10 monitors free, no card required.