Think Time and Pacing Calculator

Required virtual users = target iterations per second × iteration duration, where iteration duration = requests per iteration × (response time + think time). For 100 RPS with 5 requests per iteration, 200 ms responses and 2 s of think time, that is 20 iterations/s × 11 s = 220 VUs at minimum. With more VUs than that, pacing = VUs ÷ iteration rate sets how often each VU starts a new iteration; with fewer, a closed-model test cannot reach the target and you should switch to an arrival-rate (RPS) mode.

The formulas

A virtual user in a closed model runs an iteration (a script with k requests), waits for every response, pauses for think time after each request, and starts again. With target throughput expressed as iterations per second (X), Little's Law gives the number of VUs that must be busy at once:

X           = target_RPS / k               (or transactions_per_hour / 3,600)
D           = k × (R + Z)                  iteration duration without pacing
N_min       = ceil(X × D)                  minimum VUs to reach the target
pacing P    = N / X                        start-to-start interval per VU
max RPS(N)  = N × k / D                    ceiling for N VUs with no pacing
slack       = P − D                        time each VU idles per iteration

R is average response time per request and Z is think time per request. Pacing only makes sense when P ≥ D: a VU cannot start its next iteration before the current one finishes. If P < D, your N VUs top out at N × k ÷ D RPS no matter what the pacing setting says.

Worked example

An illustrative checkout flow: 5 requests per iteration, 200 ms average response time, 2 s think time after each request, and a target of 100 RPS (the calculator defaults).

1. Iteration rate: X = 100 ÷ 5 = 20 iterations/s.
2. Iteration duration: D = 5 × (0.2 + 2) = 11 s.
3. Minimum VUs: 20 × 11 = 220 VUs. With exactly 220 there is zero slack: any slowdown cuts throughput.
4. With 300 VUs: pacing P = 300 ÷ 20 = 15 s, so 4 s of slack per iteration. Response time can grow by 4 s ÷ 5 = 800 ms per request before the target is missed.
5. Without pacing, 300 VUs would run at 300 × 5 ÷ 11 = 136 RPS, overshooting the target by 36%.

Now say response time under load climbs to 1 s. D becomes 5 × 3 = 15 s, exactly the pacing interval, and the test is at its limit. At 1.5 s it becomes 17.5 s and 300 VUs can only deliver 300 × 5 ÷ 17.5 = 86 RPS. The test reports a lower load at the moment the system is under the most stress. That is the closed-model feedback loop explained in open vs closed workload models, and the root of coordinated omission.

Think time vs pacing

Use both when you need realistic user counts and a fixed rate. Use neither, and an arrival-rate executor instead, when what you care about is a precise request rate.

JMeter, k6, Gatling and Locust equivalents

Every major tool can do this; they differ in whether the model is closed (VUs loop and wait) or open (iterations start on a schedule).

• k6: VU-based executors (constant-vus, ramping-vus) are closed, and pacing has to be coded by hand with sleep(). The constant-arrival-rate executor is the cleaner answer: set rate and timeUnit to the iteration rate, size preAllocatedVUs to N_min, and give maxVUs headroom. Think time inside the script still counts toward iteration duration, so the VU math above still applies. If the pool runs dry, k6 logs an insufficient-VUs warning and counts dropped_iterations, which makes a missed target visible.
• JMeter: thread groups are closed. A Constant Throughput Timer (target in samples per minute, "all active threads" mode) or the Precise Throughput Timer adds delays to cap throughput at the target. Timers can only slow threads down, so the thread count must already be at least N_min. JMeter 5.5 added an Open Model Thread Group for arrival-rate style tests. The JMeter HTTP tutorial covers the basics.
• Gatling: open injection profiles such as constantUsersPerSec(20) start 20 users (iterations) per second; closed profiles such as constantConcurrentUsers keep a fixed population. Pauses map to think time.
• Locust: wait_time = between(1, 3) is think time; constant_pacing(15) makes each task run at most once every 15 s, and constant_throughput(n) sets runs per second per user. All are closed-model: the user count still caps throughput.

LoadTester offers both: VU mode, where these formulas size the VU count, and RPS mode, where you set the request rate directly and the platform holds it as response times change. For most capacity questions the RPS mode is the simpler, more honest setup; see virtual users vs requests per second.

Choosing a think time

Think time should come from data, not a habit like "1 second":

• From analytics: average time per page ≈ session duration ÷ pages per session. A 5-minute session with 4 pages means roughly 75 s between page loads, much longer than most scripts assume.
• From logs: the median gap between consecutive requests from the same session ID.
• Randomize it: use a range (for example 50% to 150% of the mean) so VUs do not synchronize into waves.
• APIs called by machines: set think time to zero and size the test by RPS instead.

Long, realistic think times push the VU count up fast. With 75 s between pages, 100 RPS of page loads needs about 7,500 concurrent users, which matches what the concurrent users calculator would give from the same traffic. That is correct if you need to test session or connection capacity, and unnecessary if you only need the request rate; the RPS calculator covers that path.

Checklist

1. Measure response time at low load and think time from real sessions.
2. Compute N_min and add 30 to 50% VUs for slack.
3. Set pacing so P = N ÷ X, or use an arrival-rate executor and skip pacing.
4. During the run, compare achieved RPS with the target. If it falls short while latency rises, you hit the closed-model limit or the system's capacity.
5. Report the result in RPS and latency percentiles, not just "300 users".