RESOURCES
RPS
Requests per second (RPS) measures how much application-level work a target completes each second under a defined scenario — not how many workers you opened.
Definition
RPS (requests per second) is the rate of successful or attempted application-level requests completed in one second. In HTTP(S) load testing it usually means how many GETs, POSTs, or API calls the system handled in that window. It answers “how much work finished,” not “how many sockets we held open.”
RPS depends on the path under test. A cacheable static GET can show high RPS while a heavy authenticated POST plateaus much earlier on the same host. Always name the scenario when you quote a number.
Related: throughput, concurrent connections, latency.
Why it matters for authorized load testing
Capacity goals are often stated as “handle N RPS at launch.” Without RPS on the chart, concurrents alone are ambiguous — more workers can raise open sessions while completed work stalls. Authorized runs use RPS together with latency percentiles and error rate to decide whether a plateau is a pass or a cliff.
Misreading RPS leads teams to oversize plans or ship false confidence. A short spike that hits a vanity peak is less useful than a stable RPS held inside abort criteria for a realistic window.
Convert between RPS and concurrents with Little’s Law on Concurrent vs RPS and the blog Concurrent connections vs RPS.
How Slammed.st uses it
In the Hub, live metrics surface request rate alongside latency and success signals during authorized Layer 7 scenarios on verified targets. Plan limits cap concurrents and duration; achieved RPS is what your infrastructure returns under that load.
Use RPS plateaus in reports to size releases and compare against pricing ceilings. Start with a free trial to learn the workflow before peak campaigns.
Glossary cluster
Browse related term pages and the hub glossary:
Reporting RPS so others can trust it
An RPS number without a scenario name, success definition, and latency budget is marketing, not capacity evidence. Say which route, which payload, which region set, and whether challenged or cached responses counted. Authorized teams file RPS plateaus next to abort outcomes so release managers can act.
Pair with concurrent connections and throughput. Calculator: concurrent vs RPS. Hub: authorized load testing.
RPS cliffs you should expect to see
- Cacheable GET plateau far above authenticated POST plateau on the same host.
- RPS stall while concurrents rise — wait/saturation.
- RPS held only while error rate exceeds budget — not a pass.
- Regional RPS skew under multi-region generators.
When RPS should not be the north-star metric
Some L4 validations care about Gbps and drops. Some product SLOs care about latency and availability first. Still, for HTTP APIs and sites, RPS remains the clearest throughput headline when reported honestly.
Index: glossary. Controls: docs. Method guide: Layer 7 stress testing.
Related
Resources hub · Glossary · Tools matrix · RPS calculator · Useful network tools · Blog · Pricing · Start free