Requests per second (RPS) is the number of requests a server or service completes in one second, typically HTTP requests to a web server, API or application backend. In server performance, it is the most common way to express throughput for request-based workloads and to describe how much traffic a system handles or can handle.
RPS only becomes meaningful when it is read together with response time and error rate. A server that completes 2,000 requests per second with a median response of 20 ms is in a very different state from one that reaches the same number with 2-second responses and frequent timeouts. Capacity figures for servers are therefore always stated as RPS at a given latency target.
How requests per second is measured
RPS is calculated by counting completed requests over a time window and dividing by the window length in seconds. Web servers, load balancers and application monitoring tools usually report it per second or per minute, sometimes as requests per minute (RPM), which is simply RPS multiplied by 60.
The choice of window matters. A one-minute average hides short bursts, while per-second sampling reveals spikes that can saturate worker pools for a few seconds. Operators often track both the average and the peak RPS over the busiest intervals.
It also matters what is counted. Requests served from a full-page cache or CDN cost far less than requests that execute application code and database queries, so a single RPS figure mixing both can be misleading. Mature monitoring splits RPS by endpoint, status code and cache result.
What determines the RPS a server can sustain
The sustainable RPS of a server follows from a simple relation known as Little’s law: concurrency equals arrival rate multiplied by time in the system. In practice, maximum RPS ≈ number of workers ÷ average service time, as long as no other resource saturates first.
For example, a PHP application with 20 PHP-FPM workers and an average processing time of 100 ms can complete roughly 200 requests per second. Halving the processing time through caching doubles the ceiling without adding hardware.
| Factor | Effect on RPS | Typical lever |
|---|---|---|
| Service time per request | Shorter time raises capacity proportionally | OPcache, object cache, query tuning |
| Worker or thread count | More parallel workers until CPU or memory saturates | PHP worker pool size, thread pools |
| CPU cores | Limits compute-heavy requests | Vertical scaling, faster code |
| Database and storage | Shared bottleneck for dynamic pages | Indexes, read replicas, caching |
| Connection handling | Setup cost per request | HTTP keep-alive, connection reuse |
Typical figures vary enormously. A static file server can reach tens of thousands of RPS on modest hardware, while an uncached content management system may manage only tens to a few hundred RPS per server, depending on page complexity.
Requests per second compared with related metrics
RPS is one of several metrics in server performance, and it is easily confused with its neighbors. The table shows how they differ and why each answers a different question.
| Metric | Unit | Question it answers |
|---|---|---|
| Requests per second | Requests/s | How much request traffic is handled |
| Throughput | Requests/s, transactions/s or MB/s | How much work or data flows overall |
| Response time | Milliseconds, often as p50, p95, p99 | How long each user waits |
| Concurrent users | Users or sessions | How many clients are active at once |
| Error rate | Percent of requests | How many requests fail |
A common error is to equate concurrent users with RPS. One hundred active visitors who each load a page every 10 seconds generate only about 10 page requests per second, plus the asset requests each page triggers.
Load testing and capacity planning with RPS
Load testing tools generate a controlled request rate and record latency and errors as the rate rises. The goal is to find the knee of the curve, the point where response times start growing sharply while RPS stops increasing, which signals resource saturation.
A sound test uses realistic request mixes, warm caches where production has them, and an open workload model that keeps sending requests at the target rate. Closed-loop tests, where virtual users wait for each response, can hide overload because they automatically slow down.
| Observation | Interpretation | Next step |
|---|---|---|
| RPS rises, latency flat | Spare capacity remains | Increase load further |
| RPS flat, latency rising | A bottleneck is saturated | Identify the limiting resource |
| RPS falls, errors appear | Overload and queue collapse | Set limits below this point |
| Latency spikes at cache expiry | Cold cache stampede | Cache warming, request coalescing |
For capacity planning, teams typically keep normal peak traffic at roughly 50-70% of the measured maximum, leaving headroom for spikes, failover and slower background tasks.
Pitfalls when interpreting RPS
- Benchmark RPS rarely matches production, because synthetic tests often hit one cached endpoint.
- High RPS with high errors is not success; failed requests are often cheap and inflate the number.
- Averages hide tail latency, so always pair RPS with p95 or p99 response times.
- Bot and health-check traffic can make up a large share of measured requests.
- Asset requests differ from page requests, so state which kind is being counted.
Put simply
Picture a coffee shop counter. Requests per second is how many orders the baristas finish every second. More baristas or faster preparation means more customers served.
But speed alone is not the whole story. A shop that serves many customers while each one waits twenty minutes is not doing well. The useful number is how many orders are finished while service stays quick, and that is exactly how engineers use RPS.
In practice
A news publisher expects heavy traffic on election night. Its web servers normally peak at about 150 dynamic requests per second, and a load test shows that response times stay under 300 ms up to roughly 400 RPS, after which the PHP worker pool fills and latency climbs above 3 seconds.
Expecting several times the usual audience, the team enables a full-page cache with a 30-second lifetime for article pages and warms it before results arrive. Most anonymous visits are now served from cache, and only logged-in users and live-results widgets reach the application.
On the night, the edge serves several thousand requests per second while the application servers stay near 250 RPS, comfortably below their measured limit, and pages stay fast throughout the evening.