All DDoS Definitions
DDoS Testing Definition

Throughput

Unlike goodput, throughput does not ask whether the traffic it counts was worth carrying; it counts everything a component moved per unit time. That makes it the capacity figure a DDoS test drives toward its limit to find where a system breaks, and the one most often misread when it does.

Throughput is always throughput of something, in some unit: bits per second on a link, packets per second through a router or firewall, requests per second at an application. A volumetric attack tries to push the first past the link's ceiling. A protocol attack tries to push the second past what a device can process or track, whatever the bandwidth.

Throughput: three ceilings, and only goodput is useful work Link bits per second ceiling: bandwidth Device packets per second ceiling: per-packet budget Application requests per second ceiling: workers and DB raw throughput goodput attack traffic filling the pipe useful throughput goodput only the rest was never legitimate work A pipe can read high bits per second while almost all of it is attack traffic. A test measures both raw throughput and goodput at every tier, mapping the rate at which raw climbs but goodput collapses. That point marks the layer of first failure. BlackNeuron™
Diagram of throughput: three separate ceilings (bits per second on the link, packets per second through the device, requests per second at the application) and raw throughput dwarfing the goodput that is actual useful work

What the datasheet number means

The benchmarking definition is narrow. RFC 1242 defines throughput as the highest rate at which a device forwards every offered frame with none dropped, and RFC 2544 measures it at a ladder of frame sizes from 64 to 1,518 bytes. A single headline figure is usually the best of those runs, on large frames, with traffic that asks the device to do very little.

Turn on the features production actually uses (stateful inspection, TLS termination, intrusion signatures, logging) and the same box often forwards a fraction of its headline rate. Many vendors publish a second, lower figure for exactly this reason. The one that matters under attack is the rate with your configuration, at the packet sizes or request mix an attacker chooses.

A system's throughput is the throughput of its narrowest stage. Raising every other ceiling changes nothing until that one moves.

Throughput past the knee: the delivered rate falls instead of flattening Zero-loss throughput Packets delivered to the app Time: offered load climbs past capacity, then is filtered Below the knee Receive livelock: CPU busy, little delivered Flood dropped before the host Delivered rate back at the knee An interrupt-driven host can spend every cycle accepting packets it never gets to finish. BlackNeuron™
Animation of throughput past the knee: packets delivered to the application hold at the zero-loss rate, fall into receive livelock as offered load climbs past capacity, and recover once the flood is dropped before the host

Past the ceiling it falls, not flattens

The intuitive picture is a plateau: offer more than capacity and the excess is dropped while delivery holds at the maximum. Real systems often do worse. Mogul and Ramakrishnan described receive livelock in 1996: an interrupt-driven kernel under overload spends its cycles accepting packets and has none left to finish processing them, so the rate delivered to applications falls toward zero as offered load keeps rising.

Linux moved to polled receive (NAPI) largely to avoid that, but the shape recurs higher up the stack. A web tier past its worker limit spends time on requests that will time out, and retries add to the offered load. So a test that only finds the knee has found half the answer. What happens beyond it decides whether the service degrades or collapses.

What a DDoS test measures about it

A test plots offered load against delivered throughput for each stage, in that stage's own unit, with production features enabled. It reads three things from the curve: the zero-loss rate, the peak delivered rate, and whether delivery holds, sags or collapses once offered load passes the peak.

It reports packets per second and bits separately, because the same device can have very different ceilings in each. It puts goodput beside raw throughput, because a busy pipe full of attack traffic still reads as high throughput.

What that means for setting a capacity baseline before the next test is worked through in DDoS Resilience Testing.