Start with questions, not tools
A useful performance test begins with a business question: can we survive a campaign with five times normal traffic, does checkout stay under an acceptable response time, how many concurrent users fit on this cluster. We agree service objectives for latency percentiles and error rates before any script is written. Then we model workload from production logs or analytics: the mix of endpoints, think times, data sizes and arrival patterns. Uniform requests against a single URL are easy to produce and misleading, because caches and connection reuse hide the real cost of each call.
Then we model workload from production logs or analytics: the mix of endpoints, think times, data sizes and arrival patterns. Uniform requests against a single URL are easy to produce and misleading, because caches and connection reuse hide the real cost. Stress tests push past capacity to see how the system fails and recovers, because graceful degradation, with sensible error messages and queues, matters as much as the headline number.
