Load test calculator for users and throughput

Little's Law says that the average number of items in a system equals the rate they arrive multiplied by the average time each one spends there. It holds for any stable system over a long enough period, whatever the distribution of arrivals or response times, which is why it is the starting point for sizing a load test.

For a load test, the items are virtual users and the time in the system is a whole user cycle: the response time plus the think time before the next action. An API with a target of 250 requests per second and a 180 ms response time, called by clients that send the next request straight away, has 250 × 0.18 = 45 requests in progress at any moment, so 45 virtual users can produce that load. A web journey with 100 users, a 0.5 s response time and 10 s of think time produces 100 ÷ 10.5 = 9.52 transactions per second.

Think time is the pause a real user takes between actions: reading a page, filling in a form. It sits inside each iteration, so it lengthens the user cycle and lowers the throughput each virtual user generates. Leave it out and every virtual user behaves like a client in a tight loop, which makes the user count in the test meaningless as a measure of real users.

Pacing fixes the interval between the start of one iteration and the start of the next, whatever the response time. It is how a closed test holds a steady rate: with 200 users and a target of 100 iterations a second, each user starts one iteration every 2 seconds. Pacing only works while an iteration finishes inside the interval. Once response time plus think time exceeds it, users start late and throughput falls below the target.

Stakeholders speak in orders a day or visitors a month. A load test needs requests per second and users. The conversion takes five steps, and each one should be written down so the target can be challenged and revised. Here is the e-commerce example the calculator opens on.

In a closed model, a fixed number of virtual users loop through the script, and each one starts its next iteration only when the last has finished. In an open model, new iterations arrive at a set rate, independently of whether earlier ones have finished. k6 offers both through its executors: ramping-vus and constant-vus are closed, constant-arrival-rate and ramping-arrival-rate are open. Gatling separates them as injectOpen and injectClosed.

The difference shows when the system slows down. In a closed model, slower responses mean longer iterations, so fewer new requests arrive and the load eases off just as the system struggles. The k6 documentation notes that this is known in some testing literature as coordinated omission. An open model keeps sending requests at the target rate, the way independent visitors to a public website do, so queues and response times grow as they would in production. Use an open model for public sites and APIs, and a closed model where the number of users really is fixed, such as an internal system with a known number of staff.

A calculated target is a hypothesis. When the test runs, compare the throughput actually achieved with the target. If throughput falls short while response times rise, the system is saturated, or the test does not have enough users. In k6 arrival-rate tests, a dropped_iterations count above zero means k6 ran out of VUs and could not start every iteration. The JMeter Constant Throughput Timer only adds pauses, so it cannot lift throughput above what the threads can deliver.

Little's Law also works as a check on the measurements: achieved throughput multiplied by the measured cycle time should come close to the number of active users. A large gap points to errors that return quickly, think time that is not what the script intends, or a load generator that has itself become the bottleneck. Judge response times by percentiles such as p95 and p99 rather than the average, and check that enough requests were collected for the percentile to be reliable.