Load Testing: What the Numbers Actually Tell You

Teams run a load test, see a green result, and assume the system is ready. Then traffic actually spikes and something falls over that the test never touched. Usually the test was measuring the wrong thing, not that testing failed.

Average response time hides the problem

A p50 of 200ms can sit next to a p99 of 4 seconds. If you only report the average, you miss the users who are actually having a bad time.

• Report p50, p95, and p99 together, not just the mean.
• Track error rate alongside latency — a fast response that returns a 500 is not a success.
• Watch what happens at the moment load ramps up, not just at steady state.

Test the shape of real traffic

A flat ramp to a fixed number of virtual users rarely matches how traffic actually arrives. Spikes, retries, and uneven request mixes change which component breaks first.

1. Model the request mix from real usage data, not a guess.
2. Include retry storms — a slow dependency plus client-side retries can multiply load on the exact service that's already struggling.
3. Run a soak test, not just a spike test. Memory leaks and connection pool exhaustion only show up after sustained load.

Know what actually broke

When a load test fails, the useful output is which resource hit its limit — database connections, thread pool, downstream API rate limit — not just "it got slow." That's the difference between a test result and a fix.

We build load test suites in k6, JMeter, or Gatling depending on the stack, and tie them to the metrics that matter for your system, not generic throughput numbers.