Performance Testing: Response Time, Latency, Throughput & Concurrent Users Explained
Understand the performance metrics teams often confuse, and turn them into a realistic workload and defensible test result.
Key takeaways
- Response time is end-to-end elapsed time; latency is only part of that wait.
- Concurrent users do not translate directly into requests per second.
- Percentiles, errors, resource signals, and workload shape must be read together.
Use precise definitions
Response time is the elapsed time observed for an operation. Latency usually describes delay before useful processing or transfer, but teams use the word differently; define where measurement starts and stops. Throughput is completed work per unit of time, such as successful checkouts per minute. Concurrency is overlapping activity, not necessarily simultaneous requests.
One thousand signed-in users who pause between actions may generate less load than fifty integrations sending requests continuously. A credible test starts with arrival rates, journey mix, think time, data, and schedules—not a round number of virtual users.
A concrete workload example
Suppose 600 users arrive over ten minutes. Each searches twice, opens three results, and saves one item, with realistic pauses. Convert that behavior into operation rates and a journey mix. Include login refresh, background calls, and cache-warm versus cold behavior. Then confirm the load generator actually produced that profile.
Read distributions, not only averages
An average can look healthy while a meaningful minority waits several seconds. Report median and selected high percentiles with sample counts, errors, and the time window. Do not compare percentiles from tiny samples or mix failed fast responses into a “good” latency result without explanation.
- Correlate response times with CPU, memory, queues, database waits, and dependency timing.
- Separate client, network, gateway, service, and downstream measurements where possible.
- Validate response correctness under load; a fast error page is not success.
- Check recovery after a spike or dependency slowdown, not only behavior during it.
Common mistakes
Avoid running heavy tests from an underpowered laptop, using identical cached data for every user, testing production without agreement, or declaring capacity from one short run. Warm-up, environment differences, monitoring overhead, and data growth can materially change the result.
What should a QA engineer do next?
Write a one-page workload model for a familiar journey. State users or arrivals, operation mix, pacing, data, duration, success criteria, and observability. Run a small baseline first, verify the generated workload, then increase demand while watching both user-facing and server-side signals.