Requests Per Second (RPS) measures how many requests your system processes each second. For API and backend teams, this is one of the fastest ways to reason about expected load.
Core Formula
In practical test planning, a common estimate is:
cycle_seconds = think_time + (response_time_ms / 1000)
RPS = (users * requests_per_flow) / cycle_seconds
This gives a baseline estimate for expected throughput under a given user behavior profile.
Worked example
Assume 100 active users, a 200 ms average response time, three seconds of think time and two requests in each business flow.
cycle_seconds = 3 + 0.2 = 3.2
RPS = (100 * 2) / 3.2 = 62.5
That 62.5 RPS is a workload target, not proof that the service can sustain it. Run the scenario and compare achieved throughput, latency percentiles and errors with the estimate.
Why It Matters
- It helps align QA, SRE, and backend on realistic targets.
- It supports infrastructure planning before expensive tests.
- It makes performance regressions easier to identify over time.
Common Mistake
Teams often compare raw RPS numbers without matching latency assumptions. If one scenario has 120 ms and another has 450 ms, direct comparison is misleading.
Use RPS together with p95/p99 latency and error rate.
Open and Closed Workload Models
The formula above describes a closed workload: a fixed group of users waits for a response and think time before repeating the flow. An open workload sends arrivals at a configured rate independently of response time. Tools such as k6 can express either behavior, and the distinction matters when the system slows down.
In a closed model, rising latency reduces the achieved RPS unless more users are added. In an open model, arrivals continue and queues can grow. Record the model in the test plan so another engineer can reproduce the result.
Evidence to Capture
For every published RPS result, retain the request mix, run duration, ramp pattern, latency percentiles, error rate and environment size. A global average can hide a slow endpoint or a short saturation interval. Break down throughput by scenario and review server-side CPU, database waits, connection pools and queue depth in the same time window.
Limits of the Estimate
The calculation assumes each configured user follows the same cycle and request count. Caching, retries, asynchronous work, uneven traffic, client limits and coordinated omission can all change observed throughput. Treat the estimate as the beginning of a testable hypothesis, not a capacity commitment.
Next Step
Use the RPS Calculator to simulate your own numbers and share a scenario link with your team.