Little's law in load testing: size and check your tests

9 October 2026 7 min read

Little’s law in load testing says that the average number of users or requests inside a system equals the rate at which they pass through it times the average time each one spends there: L = λW. With a fixed number of virtual users, that becomes users = loops per second × (response time + think time), which shows before a run whether a plan can reach its target rate and, after it, whether the results add up. It works on averages over a steady stretch of the test, so it says nothing about percentiles.

The worked examples below are arithmetic with no test run behind them. Tool facts come from each project’s documentation, checked on 9 October 2026.

Term	Little’s definition	Fixed virtual users (closed model)	Arrival rate (open model)
L	Average number of items in the system	Virtual users, waiting or pausing	Iterations in progress
λ	Average arrival rate	Loops completed per second	The rate you set
W	Average time spent inside	Response time + think time per loop	Iteration duration

What does Little’s law say?

The long-run average number of items in a queuing system equals their average arrival rate times the average time each one spends in it. Know any two of the three and you can work out the third.

John D. C. Little published the proof in 1961 in Operations Research as A Proof for the Queuing Formula: L = λW. His 50th-anniversary review of 2011 says it holds under remarkably general conditions: for one queue or a whole network, for a subclass of items or all of them, and whatever the order of service. It also maps the terms onto a server: requests in process, requests per second and average response time.

What do L, λ and W mean in a load test?

That depends on where you draw the boundary. Around the server, L is the requests in progress and W is response time; around a virtual user’s whole loop, L is every virtual user and W is response time plus think time.

In a closed-model test each user is always somewhere in its loop, waiting for a response or pausing between steps. With the boundary around the loop, all of them count as inside, λ is the rate at which loops complete, and W is the average loop time, including the think time the script adds:

users = loops per second × (response time + think time)

Around the server, the same law gives the requests in flight: requests per second × average response time, the figure your connection pools and worker threads must hold. Keep all three numbers on one boundary and one stretch of time; mixing them gives plausible wrong answers.

How do you size a closed-model test with Little’s law?

Turn the target request rate into loops per second and multiply by the expected time per loop: the result is the number of virtual users the plan needs. Use the response time you expect at the target load, which is usually higher than what a few users see.

A worked example, arithmetic only. The goal is 100 requests per second, each loop sends 4 requests expected to take 0.5 seconds each, and the script pauses 3 times for 2 seconds on average:

loops per second = 100 requests/s ÷ 4 requests  = 25
time per loop    = 4 × 0.5 s + 3 × 2 s          = 8 s
virtual users    = 25 loops/s × 8 s             = 200

Treat 200 as the minimum. If responses take 1 second at that load, a loop lasts 10 seconds and the same target needs 250 users.

Why do the same users send fewer requests when the system slows down?

The number of users is fixed, so when the time per loop grows, the loops per second must shrink. The load falls just as the system starts to struggle.

Keep the 200 users and let each request take 2 seconds. A loop now lasts 4 × 2 + 6 = 14 seconds, and 200 ÷ 14 gives about 14.3 loops, or about 57 requests per second. The test still shows 200 users while running at little over half the planned rate. The open vs closed workload model article explains why that hides saturation; Little’s law predicts the size of the drop.

It also shows what a capacity limit looks like. Once the request rate cannot rise, each extra user adds only waiting: at a ceiling of 25 loops per second, 300 users mean 12 seconds per loop and 400 users mean 16. LoadFocus’s response time vs virtual users chart plots average and maximum response time against active virtual users, one point per user level reached, which is where that steady climb shows up.

How do you check a finished test against Little’s law?

Take the average request rate and response time from a stretch where the user count stayed flat, rebuild the number of users from them, and compare it with what you configured. A large gap means time is going somewhere your numbers do not show.

Another arithmetic example. A run holds 200 users and reports 80 requests per second at a 0.6-second average, with the same 4 requests and 6 seconds of pauses per loop. That is 20 loops per second at 4 × 0.6 + 6 = 8.4 seconds each, enough for 168 users. The other 32 mean each loop really took 10 seconds, so about 1.6 seconds per loop is unexplained. Places to look:

Connection setup. In k6, http_req_duration leaves out DNS lookup and connecting (metrics reference, checked on 9 October 2026).
The load generator. A busy generator delays the script between requests.
Think time. Random pauses can average more than the plan says.
The window. If it overlaps a ramp, fewer users were active on average.

k6 also measures the loop directly: vus counts active virtual users and iteration_duration times one full iteration, so active users should land close to iterations per second × average iteration duration.

What about arrival-rate tests?

The law holds with the boundary around each iteration: iterations in progress equal the arrival rate times the iteration duration. That is how many virtual users the tool must keep ready.

The k6 guide to allocating VUs for arrival-rate executors estimates them as median iteration duration × rate, plus a constant for variance (checked on 9 October 2026). That is Little’s law with the median standing in for the mean; a few slow iterations pull the mean above the median, so the margin matters.

LoadFocus runs k6 scripts in its cloud, and there arrival-rate scenarios run with a fixed number of users; the script validator warns about it when you add such a script. Size those tests with the closed-model arithmetic above and expect the rate to fall if responses slow down.

Where does Little’s law stop working?

It ties together averages over a stretch where the system is in balance. Percentiles, short windows and ramps fall outside it.

Averages only. A run can satisfy the law while one request in twenty waits ten times the mean, so judge results on percentiles too.
A steady stretch. The 1961 proof assumes a stationary process, and the 2011 review shows the formula is also exact over a finite window that starts and ends empty. A test plateau is neither, so pick a long one, where users finishing loops keep pace with users starting them.
Ramps. While users are being added, the configured peak is not L: use the window’s time-averaged user count, or leave the ramp out.
Errors. Fast failures count as completed requests with short times, so a failing system can still balance the equation. Check the error rate first.

FAQ

Does Little’s law need Poisson arrivals or a particular queue? No. The proofs in Little’s review make no assumption about the arrival pattern or service times, and the result holds whatever the order of service. It needs only averages that exist over the period you measure.

Can Little’s law predict p95 response times? No. It links three averages, so it can check a mean response time, but it says nothing about the shape of the distribution or the slowest few percent.

The technical claims in this article have not been independently reviewed.

LoadFocus team

Written by the LoadFocus team, the people behind a cloud load testing service.