# RPS calculator

> Plan a load test before you run one.

The RPS calculator estimates the throughput in requests per second that a given number of concurrent virtual users will actually generate, so you can size a load test before running one instead of discovering the number afterwards.

Also: rps calculator, requests per second calculator, throughput calculator, api throughput calculator, requests per second, load capacity planning, concurrent users to rps, load test calculator, virtual users calculator.

## What it does

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.

## When to use it

- You know the requests per second you need to support and want to work out how many virtual users produce it.
- You want to check whether a planned test is actually a load test or just a smoke test.
- You need to predict egress bandwidth before a test saturates the machine generating the load.
- You are choosing between a fixed, ramp, spike or peak load profile and want to see the shape each produces.

## What you give it

| Input | Meaning |
| --- | --- |
| Virtual users | Concurrent users in the test, each running requests sequentially. 1 to 1,000. |
| Average response time | How long the server takes to return a full response, in milliseconds. 1 to 5,000. |
| Think time | The pause a user waits between receiving a response and sending the next request, in milliseconds. 0 to 30,000. |
| Average response size | Payload size in KB, used to derive egress bandwidth. |
| Burst multiplier | A peak factor applied to the steady-state figure. 1x, 2x, 3x or 5x. |

## What you get back

| Output | Meaning |
| --- | --- |
| Requests per second | Steady-state throughput for the inputs given. |
| Per minute, hour and day | The same throughput projected out, for comparing against quota and rate limits. |
| Peak throughput | Steady-state requests per second multiplied by the burst factor. |
| Egress bandwidth | Megabits per second implied by throughput and payload size. |
| Throughput-versus-latency curve | How requests per second fall as response time rises, with your current point marked. |
| Load profile shape | Virtual users plotted over the test duration for the selected profile. |

## How it works

- Cycle time = average response time + think time — the full duration of one virtual user loop.
- Requests per second = virtual users ÷ cycle time in seconds. This is Little's Law applied to a closed loop, where concurrency is fixed and throughput is what varies.
- Peak requests per second = steady-state requests per second × the burst multiplier.
- Egress in Mbps = requests per second × average response size × 1024 × 8 ÷ 1,000,000.
- Throughput is inversely proportional to cycle time, so halving response time doubles requests per second only when think time is zero — with think time dominant, latency improvements barely move throughput at all.

## Key terms

- **Virtual user** — one simulated client running a closed loop: send, wait for the full response, think, send again. It is not one request — it is a sequential worker.
- **Think time** — the pause between a user receiving a response and sending their next request. It models human reading and typing, and it usually dominates cycle time. Set it to zero and you get a throughput ceiling rather than a traffic model.
- **Little's Law** — the queueing-theory result that concurrency equals throughput multiplied by residence time. Rearranged for a closed loop, throughput equals concurrency divided by cycle time, which is the formula this calculator applies.
- **Closed loop** — a load model where a fixed number of users each wait for a response before continuing, so the system's own slowness throttles the offered load. An open loop injects requests at a fixed rate regardless of whether the server keeps up.
- **Fixed profile** — all virtual users start at once and hold for the whole run — a steady-state soak test.
- **Ramp up profile** — users are added gradually. Holds the initial load for the first quarter of the run, ramps to peak over the next quarter, then holds peak. Finds the point where latency starts to climb.
- **Spike profile** — a short burst well above baseline, then a drop back. Tests recovery behaviour and cold caches.
- **Peak profile** — up, hold, then down. The closest shape to a real traffic event such as a launch or a sale.

## Questions

### 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.


## Privacy

The calculation runs entirely in your browser. Nothing you enter is uploaded, and no account is needed — the tool sends no requests to your API, because it models throughput rather than measuring it.

## Links

- [Use the tool](https://www.postman.com/tools/rps-calculator) — the interactive version of this page.
- [Postman Tools](https://www.postman.com/tools) — every free tool in this set.
- [Performance testing docs](https://learning.postman.com/docs/collections/performance-testing/testing-api-performance/) — Postman documentation.