The Stress Test Report Is Lying to You
Most stress testing panels generate a report after each run. Throughput in Gbps, request rate in RPS, duration, target status. Looks scientific. But the majority of those reports are either misleading or actively wrong.
Here's how to actually read one.
1. Gbps vs PPS: Which Number Matters?
A report that says "12.5 Gbps" tells you nothing without the packet rate context.
- 12.5 Gbps at 8.2M PPS = large packets (~1900 bytes each), likely saturating bandwidth
- 12.5 Gbps at 142K PPS = tiny packets (~64 bytes), likely forged/synthetic
The first scenario means the target's pipe is full. The second means something else entirely — possibly a middlebox is rate-limiting, possibly the packets never reached the origin.
Rule: Always read Gbps and PPS together. One without the other is a vanity number.
2. The "Success" Column Is Not What You Think
Most panels show a per-request status: 200, 403, 502, 503, timeout.
A column full of 200 looks like "it worked." But if the target is a CDN edge node returning a cached error page, every request gets a 200 while the origin is already down.
| Status | What it might mean | What it probably doesn't mean |
|---|---|---|
| 200 | Page served | Origin is healthy (could be CDN cache) |
| 403 | WAF blocked | Server is up and defending |
| 502 | Origin unreachable | CDN can't reach backend — this is the kill |
| 503 | Service overloaded | Capacity exceeded — partial success |
| Timeout | Packet dropped | Firewall silent-drop or link saturated |
The only statuses that reliably indicate origin impact are 502 and timeout. A report dominated by 403s means the target's defense is working, not failing.
3. The Ramp Curve Tells the Real Story
A flat throughput graph means the test never hit the target's ceiling — it was rate-limited by the testing infrastructure, not the target.
A healthy stress test report should show three phases:
Phase 1 (0-30s): Linear ramp — throughput climbs as workers scale up
Phase 2 (30-60s): Plateau — sustained max throughput, target still responding
Phase 3 (60-90s): Collapse — target response times spike, status codes shift
If you see Phase 1 → Phase 2 with no Phase 3, your test was too weak. If you see Phase 1 → immediate collapse, your target has no redundancy at all.
4. Response Time Is the Hidden Metric
Throughput tells you volume. Response time tells you impact.
- Baseline: 45ms
- Under load: 45ms → 120ms (CDN absorbing, origin stressed but alive)
- Degraded: 120ms → 800ms (queue building, workers exhausted)
- Failed: 800ms → timeout (connection pool drained)
A target that holds 200 status codes but goes from 45ms to 800ms response time is functionally down for real users. Most reports bury this metric — dig for it.
5. Geographic Distribution: The Blind Spot
If your test originates from 3 locations and the target has a global CDN with 280 PoPs, you're testing 1% of the attack surface.
A report showing "target down in 15 seconds" from a single-origin test means nothing if the production traffic comes through 12 different edge locations. The CDN will route around your test traffic.
What to look for: reports that include multiple source regions AND note the CDN's behavior per region, not just aggregate.
Putting It Together
A real stress test report should answer three questions:
- Did the origin actually fail (502/timeout), or just the edge (403/429)?
- At what load did the transition happen (PPS + Gbps at the inflection point)?
- How long did it take to recover after the test stopped?
If your report can't answer all three, you're reading a vanity dashboard, not a test result.
References: DDoS压力测试完整指南
Top comments (0)