All DDoS Definitions
DDoS Testing Definition

Requests Per Second (RPS)

Requests per second (RPS) measures how many HTTP or HTTPS requests an application receives each second, often expressed at DDoS scale as kilo-requests per second (KRPS). Under attack the number counted at the edge and the number reaching the origin can differ by orders of magnitude, or not at all, depending on what the cache can answer, which is why a DDoS test reports RPS at each tier alongside the latency and error rate the origin returns.

RPS is the dimension that defines application-layer (L7) floods. Each request is small on the wire but expensive at the origin, where it costs CPU, a worker thread, sometimes a TLS handshake, and often a database query, so a modest bandwidth figure can still exhaust the backend.

Requests per second: cheap on the wire, costly at the origin Clients / bots many HTTP requests small on the wire small requests Origin (app tier) each request is expensive: TLS handshake worker thread CPU cycles DB query bandwidth on the wire modest Gbps request rate (RPS) worker pool and database exhausted at a few KRPS A test drives RPS at the expensive endpoints, where small requests still exhaust CPU, worker threads, and the database. BlackNeuron™
Diagram of requests per second: small HTTP requests that are cheap on the wire but expensive at the origin, where RPS exhausts worker threads, CPU, and the database at a few KRPS

Why the same RPS is not the same load

L7 attacks are measured in request rate, not bandwidth, because the cost lives in the application, not the link. A server that streams video happily at 10 Gbps may fall over at a few thousand RPS of uncached dynamic requests.

Two requests per second can differ a thousandfold in cost. A cached image is answered at the edge and never touches the origin. A login runs a deliberately slow password hash. A search query or a checkout fans out into several database calls. An HTTP flood aimed at the expensive kind needs a small fraction of the rate one aimed at the homepage would, and a cache-busting attack exists to turn the cheap kind into the expensive kind by making every request miss.

RPS is also not connections per second. With keep-alive and HTTP/2, one connection carries many requests, so a flood can push high RPS through a handful of connections, or open a new TLS session for every request and spend the server's CPU on handshakes instead.

Where the ceiling comes from

The ceiling is usually set by concurrency, and the arithmetic is Little's law: requests in flight equal the arrival rate times the time each one takes. A pool of 200 workers at 100 ms per request serves 2,000 RPS. If a slow database stretches each request to one second, the same pool serves 200.

That is why an L7 flood often looks like a latency problem before it looks like a rate problem. The attack does not have to reach 2,000 RPS. It only has to slow each request down enough that the pool fills at the rate it does send.

Requests per second: the rate the origin can actually serve served rate at normal latency requests served per second time, through an uncached L7 flood pool has headroom slow requests pin every worker expensive path rate limited served RPS back to baseline Workers in flight equal arrival rate times time per request, so a flood that stretches each request from 100 ms to one second cuts the served rate tenfold. BlackNeuron™
Animation of requests per second: served requests hold at baseline, collapse when an uncached flood pins the worker pool, and recover once the expensive path is rate limited

What a DDoS test measures about it

A test drives RPS against the expensive endpoints to find where worker pools, connection limits, and the database tier give out. It records:

  • RPS at every tier. Arriving at the edge, passed by the WAF, forwarded by the load balancer, received by the origin. The ratio between them says what each layer is actually absorbing.
  • The knee per endpoint class. The rate at which latency leaves its band for static, dynamic, authenticated and search requests separately, because one blended number hides the cheap path covering for the expensive one.
  • Served versus received. The rate of successful responses within the latency target, which is goodput for an application, set against the rate arriving.

The application-layer attack classes behind this metric are covered in L7 DDoS testing.