What does this calculator show beyond the raw number?
The most common load-testing mistake is assuming 100 virtual users produce 100 requests per second. They do not. A virtual user is a closed loop — send a request, wait for the full response, pause, send the next — so throughput is governed by how long each cycle takes, not by the user count alone. This tool applies that relationship, shows the derivation, and plots how throughput collapses as response time grows.
Why do 100 virtual users not produce 100 requests per second?
Because each user waits for a full response and then thinks before sending again. With a 120ms response and 1 second of think time the cycle is 1.12 seconds, so 100 users produce about 89 requests per second, not 100. Raise think time to 5 seconds and the same 100 users produce under 20
How many virtual users do I need for a target requests per second?
Multiply your target requests per second by the cycle time in seconds. For 500 requests per second with a 200ms response and 1 second of think time, the cycle is 1.2 seconds, so you need roughly 600 virtual users
Should think time be zero?
Only when you are deliberately hunting for a ceiling. Zero think time means users hammer the endpoint back to back, which finds the breaking point but does not model real traffic
Why does the estimate differ from a real test run?
This is an open-loop arithmetic estimate that assumes response time stays constant as load rises. In a real run it does not — queueing makes responses slower under load, so measured throughput comes in below the estimate. The gap is the queueing you cannot see from a calculator
What is the burst multiplier for?
It applies a peak factor to steady-state throughput, so you can size for traffic spikes rather than for the average