load-testing

Load testing

A load test answers one of two questions, and confusing them wastes the effort:

• Can it handle X?: a specific, known target. Verification.
• Where does it break, and how?: the ceiling and the failure mode. Discovery.

Discovery is usually more valuable. Knowing you handle 1,000 requests per second tells you less than knowing that at 1,200 the connection pool exhausts and every request hangs for 30 seconds rather than failing fast.

1. Model realistic traffic, not a single endpoint

Hammering one endpoint measures that endpoint. Real systems fail through interaction — a slow report query saturating the pool that the login path needs.

Model:

• The mix: which endpoints, in what proportion, from real traffic data
• The shape: steady, spiky, or diurnal. A ramp reveals different problems than a sudden step
• Think time: real users pause. Zero think time produces an unrealistic connection pattern
• The data distribution: everyone hitting one hot row behaves nothing like a spread of keys. This is a very common cause of misleading results

Done when: the generated traffic resembles what production actually sees.

2. Test something that resembles production

A load test against a laptop tells you about the laptop.

Match, or document the difference: instance sizes, replica counts, database size and data volume, network topology, and — critically — caches in a realistic state. A cold cache and a fully warm one give completely different numbers, and neither may be the steady state.

Done when: you can state how the environment differs from production and how that skews the result.

3. Ramp, and watch for the knee

Do not start at target load. Ramp, and watch for the point where the response curve bends.

Below saturation, latency stays roughly flat as throughput rises. At the knee, latency climbs sharply while throughput stops rising. That point is your real capacity, and it is usually well below the number where errors start.