12. Checklists & Common Pitfalls
Before running any load test
- Confirm you're not accidentally load-testing a shared staging environment other teams depend on, or (never) production without explicit sign-off.
- Warm up caches/JIT/connection pools deliberately, or explicitly include cold-start behavior as part of what you're measuring — decide which, don't let it happen by accident.
- Verify the load generator's own host isn't the bottleneck (check its CPU,
socket/file-descriptor limits —
ulimit -n, and outbound ephemeral port exhaustion under very high connection-per-request rates). - Decide open-loop vs. closed-loop deliberately based on what you're modeling (§3.4) — don't default to whatever the tool ships with.
- Synchronize clocks (NTP) between load generator and server if correlating timestamps across systems.
Common pitfalls
- Coordinated omission: closed-loop tools under-sample exactly the slow
periods, making reported percentiles look better than reality. Use
wrk2,vegeta, or k6's arrival-rate executors for anything you'll make a capacity decision from. - DNS caching skew: if the load generator resolves DNS once and the real clients don't (or vice versa), the two won't see comparable connection-setup costs.
- Same-machine test skew: running the load generator on the same host as the server steals CPU from the very thing you're measuring, and localhost network stack behaves nothing like a real network path.
- Ignoring warm-up in results: including the first 10-30s of a ramp (JIT warm-up, connection-pool fill, autoscaler lag) in your percentile calculation skews everything pessimistic in a way that isn't steady-state reality.
- Testing only the happy path: also fire malformed/oversized payloads, expired auth tokens, and duplicate idempotency keys under load — correctness under concurrency (§6.3) is as important as raw speed.
- One global percentile hides per-tier behavior: segment latency by endpoint, user tier, and payload size (§6.4) — a global p99 can look fine while a specific critical path is badly broken.
- Not testing failure/recovery, only steady load: spike tests and dependency fault-injection (§8.2) reveal how the system behaves while breaking and while recovering — both matter more operationally than steady-state numbers.