RPS calculator

Estimate the throughput (requests per second) your API sees from concurrent users, response time, and think time, with live charts. Runs in your browser, no account needed.
Load shape
Multiplier for the peak you plan capacity against
Cycle = Response time + Think time
Cycle = 120ms + 1000ms = 1.12s
RPS = Virtual users ÷ Cycle
RPS = 50 ÷ 1.12s ≈ 44.6 req/s
Peak = RPS × 2 ≈ 89 req/s

Little's law on a closed loop: each virtual user sends, waits for the full response, thinks, then sends again. It assumes latency holds steady as load grows. Real services queue, so measured throughput bends below this.

Estimated throughput
45req / s
Per minute
2,679
Per hour
160,714
Peak (2× burst)
89 req/s
Egress
1.8 Mbps
Per day
3,857,143
Throughput vs response timeat 50 VUs
Every extra millisecond of latency costs you requests per second.
A sensible starting point. Compare a measured run against 45 req/s. The gap is queueing you cannot see from here.
Estimates end here. Postman measures the rest. A run also has a shape. Pick one of Postman's four load profiles to see how virtual users are distributed across your 10-minute test.
Load profile
Fixed
peak 50 VUs
50 virtual users run for 10 minutes, each executing all requests sequentially.
What the maths assumes
One virtual user is one closed loop: send, wait for the full response, think, send again. It assumes latency stays flat as load grows. Real services queue, so measured throughput bends away from this estimate well before the numbers do.
Then measure it in Postman
Performance and Load testing runs a collection you already have at these virtual users and reports throughput, 90th-percentile response time and error rate live, broken down per request, so you can see which endpoint bent first.

Compare what you unlock

  • What you can doEstimate theoretical throughput
  • Output metricsTarget Requests Per Second (RPS) based on think time
  • RegressionsCannot identify performance regressions
  • Test real APIsNot included
  • Real user trafficNot included
  • AutomationNot included

FAQ

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