Performance Test Design
Constructing a load test whose result predicts production behaviour rather than merely producing numbers.
Most performance testing produces confident, meaningless output because of a handful of design errors that are easy to name and easy to avoid.
Unrealistic workload mix. Hammering one endpoint at maximum rate tells you about that endpoint. Production is a mix of operations with a specific ratio, arriving with think time and bursts, and system behaviour under a mix differs sharply from behaviour under a single hot path.
Unrealistic data. A test dataset of 10,000 rows exercises entirely different query plans and cache behaviour than 100 million rows with skewed distribution. This single factor invalidates more performance tests than any other.
Warm caches and repeated keys. Requesting the same 100 records repeatedly gives a cache hit rate production will never see.
Coordinated omission. A load generator that waits for a response before sending the next request reduces its own rate exactly when the system slows, which systematically hides the tail latency you are testing for. Use an open-model generator that maintains arrival rate independently.
And measure the right thing: report percentiles and the full distribution, run long enough for resource leaks and garbage collection patterns to appear, and always identify the bottleneck rather than just recording the number.