Metrics & Measurement
What Is Requests Per Second (RPS)?
Requests per second is the number of HTTP requests a system handles each second — the most common concrete unit for expressing load test throughput.
Also known as: RPS, QPS, Queries Per Second
RPS, TPS, and throughput
RPS counts individual HTTP requests. Transactions per second counts completed business operations, and one transaction usually spans several requests — a checkout might be six. Throughput is the general term for both, plus rates measured in bytes or messages.
Mixing the units is a reliable way to be wrong by an order of magnitude. “We handle 500 per second” means very different things depending on whether the unit is a page view, an API call, or an asset fetch, and stating which one is the difference between a useful figure and a misleading one.
Average RPS hides the peaks that hurt
A million requests spread over an hour averages 278 per second, and a system sized for that number will fall over — because those requests are not spread evenly. Real traffic clusters, and the peak minute frequently carries several times the hourly mean.
Size for the peak, and derive it from short windows. Take the busiest minute from production, divide by 60, and add margin. A peak-to-average ratio of three or four times is ordinary for consumer traffic, and higher for anything driven by campaigns, notifications, or scheduled jobs.
From RPS target to virtual user count
The conversion is mechanical once you know the journey. Per-VU rate = 1 ÷ (server time + think time), so a journey costing 1 second of server time and 4 seconds of think time yields 0.2 requests per second per VU — meaning a 1,000 RPS target needs roughly 5,000 VUs.
Treat that as a starting point and verify it during the run. If the system slows under load, per-VU rate falls with it and the same pool delivers less than the arithmetic promised.