load-testing

Topics in the source

• Load testing
• 1. Model realistic traffic, not a single endpoint
• 2. Test something that resembles production
• 3. Ramp, and watch for the knee
• 4. Measure the right things
• 5. Do not test in production carelessly
• Report

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. 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. A load test against a laptop tells you about the laptop. Match, or document the difference: instance sizes, replica counts, database size and da

This is an excerpt. Refer to the complete source and its current requirements.