Requests per Second (RPS) Calculator

Average RPS = daily requests ÷ 86,400. Peak RPS = average RPS × your peak-to-average factor, and the load test target is peak RPS plus headroom. For example, 8 million requests a day is 92.6 RPS on average; with a 3× peak factor and 50% headroom you should test at about 417 RPS. The calculator below does this, and its reverse mode converts virtual users, response time and think time into the RPS they actually generate.

The formulas

Forward mode turns traffic volume into a load test target:

daily_requests = daily_users × requests_per_user     (or entered directly)
avg_RPS        = daily_requests / 86,400
peak_RPS       = avg_RPS × peak_factor
target_RPS     = peak_RPS × (1 + headroom% / 100)

Reverse mode answers the opposite question: if I run N virtual users, what request rate will they produce? Each VU in a closed loop sends a request, waits for the response (R), pauses for think time (Z), and repeats. By the interactive form of Little's Law:

RPS = N / (R + Z)

This is the formula that explains most "my test isn't hitting the RPS I expected" problems. R is not a constant; it grows as the server saturates, and every millisecond it grows reduces the RPS a fixed set of VUs can generate.

Worked example

An illustrative API with 200,000 daily active users, each making about 40 requests a day (the calculator defaults):

1. Daily requests: 200,000 × 40 = 8,000,000.
2. Average RPS: 8,000,000 ÷ 86,400 = 92.6 RPS.
3. Peak RPS: with a measured peak factor of 3, 92.6 × 3 = 277.8 RPS.
4. Target: 277.8 × 1.5 = 416.7 RPS. Round to 420 RPS for the steady-state stage.

Reverse check: to produce 420 RPS in VU mode with 250 ms responses and 1 s of think time, you need N = 420 × 1.25 = 525 VUs. If response time doubles to 500 ms under load, those same 525 VUs only produce 525 ÷ 1.5 = 350 RPS. The test quietly backs off exactly when the server struggles. That is the closed-model trap described in open vs closed workload models.

Quick reference: daily volume to average RPS

One million requests a day sounds like a lot and is about 12 requests per second. Many teams overestimate the load they need by an order of magnitude, then underestimate the peak factor. Do the arithmetic before buying hardware or a bigger load testing plan.

Finding your peak-to-average factor

The peak factor is the number that matters most and the one most often guessed. Measure it from access logs or your metrics system:

# requests per hour from an nginx access log (default combined format)
awk '{print substr($4, 2, 14)}' access.log | sort | uniq -c | sort -rn | head -5

peak_factor = (busiest_hour_requests / 3,600) / (daily_requests / 86,400)

If your busiest hour holds 10% of the day's requests, the factor is 0.10 × 24 = 2.4. If you only know sessions per hour, the concurrent users calculator converts a peak-hour share into RPS directly.

Two refinements matter for tight systems:

• Per-minute peaks. An hourly average hides bursts. If your metrics have one-minute resolution, compute the factor from the busiest minute instead. It will be higher.
• Endpoint mix. 400 RPS of cached GETs and 400 RPS of checkout POSTs are different tests. Split the target by endpoint using the ratios in your logs; see how to load test an API for building a mixed scenario.

Using the target RPS in a load test

A target RPS is most reliably reproduced in an arrival-rate (open model) executor, where the tool starts requests on a schedule regardless of how long previous ones take:

• k6: the constant-arrival-rate or ramping-arrival-rate executor.
• Gatling: open injection profiles such as constantUsersPerSec, which sets user arrivals per second (multiply by requests per user to get RPS).
• JMeter: a Constant Throughput Timer or Precise Throughput Timer on a thread group (still bounded by thread count), or the Open Model Thread Group added in JMeter 5.5.
• Vegeta: -rate=420/s, which is open-model by design.
• LoadTester: RPS mode, where you enter the request rate directly and the live charts show whether it was held.

If you stay in VU mode, use the reverse calculation to size the VU count, then verify on the RPS chart that the achieved rate matches the target for the whole test. A run that shows 420 RPS for the first two minutes and 300 RPS after latency rises did not test 420 RPS. The think time and pacing calculator adds multi-request iterations and pacing to the same math.

From target RPS to a test plan

1. Compute average, peak and target RPS above with a measured peak factor.
2. Ramp from 0 to the target over a few minutes rather than starting cold at full rate.
3. Hold the target long enough for caches, connection pools and autoscaling to settle.
4. Set thresholds on p95 latency and error rate; see how to read load test results.
5. Then step beyond the target in a stress test to find where throughput stops rising and latency climbs.