DevOps

Load Test Concurrency Calculator

Convert between virtual users, requests per second and response time using Little’s Law, size a load test correctly, and see why adding users past saturation measures queueing rather than capacity.

Last reviewed by the Radiatus Cloud team

Calculation appears here.

Want this automated for your stack?

We build CI/CD, Kubernetes & IaC pipelines that scale.

Talk to an engineer

Virtual users and requests per second are not the same thing

Load tests are usually specified in virtual users and systems are usually specified in requests per second, and converting between them is where most load testing goes wrong. Little's Law gives the relationship: concurrency equals throughput multiplied by response time. A hundred virtual users with a two hundred millisecond response time and no think time generate five hundred requests per second. Add a one second think time and the same hundred users generate only eighty three. The think time is not a detail, it changes the answer by a factor of six.

Past saturation, more users measure the queue

Below the saturation point, adding virtual users increases throughput and response time stays flat. At saturation, throughput stops rising and response time begins increasing in direct proportion to the users added, because every additional user simply joins a queue. Beyond that, throughput often falls as context switching and memory pressure take over. A test that reports "the system handled two thousand users" without reporting response time is describing a queue, not a capacity.

Ramp and duration matter as much as load

Starting at full load measures cold caches, empty connection pools and an unwarmed JIT, none of which represent steady state. A ramp of a few minutes lets the system reach its normal operating condition. Equally, a short test misses garbage collection pauses, connection pool exhaustion, log rotation and memory growth, all of which appear over tens of minutes. A ten minute steady state after the ramp is a reasonable minimum for anything you intend to draw conclusions from.

Related tools

Frequently Asked Questions

How do I convert virtual users to requests per second?

Throughput equals concurrency divided by the sum of response time and think time. Fifty users with a 200 ms response and a 1 s think time produce 50 / 1.2, which is about 42 requests per second, not 250.

What is think time and does it matter?

The pause a simulated user takes between requests. It matters enormously: without it, each virtual user hammers continuously and represents far more load than a real user. Omitting think time is the most common reason a load test result does not match production behaviour.

How do I find the saturation point?

Ramp the load and watch where throughput stops rising while response time starts climbing linearly. That knee is the capacity. Load applied beyond it measures how the queue behaves, which is useful for failure mode testing and useless for capacity planning.

How long should a test run?

At least ten minutes at steady state after the ramp, and considerably longer for anything memory related. Garbage collection pauses, connection pool exhaustion and gradual memory growth all appear over tens of minutes and are invisible in a two minute run.

Should I test from one machine?

Only if that machine can generate the load without saturating itself. A single load generator commonly becomes the bottleneck through CPU, ephemeral port exhaustion or its own network limit, and then the test measures the generator rather than the target.

Privacy & Security

Everything runs in your browser; nothing is uploaded.

Data: None
Client-side-Side
Active
v1.0

How to Use

Enter any two of throughput, concurrency and response time to derive the third.

Disclaimer: This tool is provided "as is" without warranty of any kind. Results are for educational and utility purposes.