Load Testing: Finding the Breaking Point Before Your Users Do

Most load testing produces a reassuring graph and no information. The useful version answers two questions: at what point does the system stop meeting its response-time target, and which component gives way first?

Four tests, four purposes

• Load test — expected peak traffic, sustained. Confirms you meet your targets under normal worst-case conditions.
• Stress test — increase until something breaks. Tells you the actual ceiling and the failure mode, which is the most valuable output.
• Soak test — moderate load for hours. Finds memory leaks, connection exhaustion, and log volume problems that short tests never surface.
• Spike test — sudden surge, as from a campaign or a news mention. Tests autoscaling reaction time, which is usually slower than people assume.

Realism is everything

• Production-scale data. A query against 10,000 rows tells you nothing about its plan on ten million.
• A realistic journey mix — browsing, searching, checkout — weighted as your analytics shows, not all hitting one endpoint.
• Think time between requests. Users pause; a test without pauses measures a stampede that will never happen.
• Cold caches at the start, and distinct accounts and records per virtual user, or you'll measure your cache rather than your system.

Reading the results

• Look at percentiles. An average hides the slowest 5%, which is where the complaints come from.
• Find the knee — the concurrency at which latency starts climbing steeply. That's your real capacity, not the point where errors appear.
• Correlate with server-side metrics: database connections, CPU, queue depth. Without them you know that it broke, not why.
• Errors under load are often the more useful finding: timeouts, connection pool exhaustion, and rate-limited third parties.

Practical warnings

• Test in an environment that matches production in shape, and state clearly where it doesn't.
• Warn any third parties you'll be calling, and stub the ones you shouldn't hammer.
• Never load test production without an agreed window, a kill switch, and someone watching.
• Re-run after significant changes. A capacity figure from a year ago is a historical note, not a plan.