Load Test Concurrency Calculator

Work out load test concurrency instantly with clear inputs, formula shown and shareable results.

About Load Test Concurrency Calculator

Virtual users and requests per second are not the same thing. Each virtual user completes one request per cycle of response time plus think time, so achieving 1,500 requests per second with a 3.2-second cycle needs about 4,800 virtual users. Concurrency at the server is much lower, because think time is spent idle — confusing the two is the most common load-test sizing error.

Formula

Virtual user count

cycle = response time + think time; virtual users = target RPS x cycle; server concurrency = target RPS x response time

Worked example

With the default values below, Load Test Concurrency Calculator returns Virtual users required of 4,830. Change any input above and every figure here is recalculated in your browser.

Inputs used

Target throughputminimum 0.01 req/s: 1,500 req/s
Expected response timeminimum 0.1 ms: 220 ms
Think time between requestsminimum 0 s: 3 s
Requests per second per generatorminimum 0.01: 400

Results

Virtual users required: 4,830
Requests in flight at the server: 330.0
Load generators required: 4
Seconds per user request cycle: 3.220 s

Step by step

1Values used
2Virtual user count
3Virtual users required= 4,830
4Requests in flight at the server= 330.0
5Load generators required= 4
6Seconds per user request cycle= 3.220 s

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax or compounding frequency into account.
Figures are rounded for display to 3 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

Why include think time at all?

Because it models real user pacing and connection reuse. Removing it produces a hammering pattern that stresses different bottlenecks than production traffic does.

What if the load generator becomes the bottleneck?

Then the test measures the generator, not the service. Watch generator CPU and socket limits, and distribute across enough hosts that they stay well below saturation.