Performance metrics describe different aspects of system behavior. RPS describes request intensity, throughput measures completed work, latency measures delay within defined boundaries, and percentiles reveal timing distributions. Confusing them can produce a convincing graph and an incorrect conclusion.
QA benefits from asking several related questions: how much work arrived, how much completed successfully, how long users waited, and what happened to the queue. One number rarely answers all of them.
RPS: requests per second
RPS means requests per second. Clarify where requests are counted: by the generator when sent, the load balancer when received, or the application after completion. During an unstable interval, these counts differ because of queues, disconnections, and unfinished operations.
Record the aggregation interval and observation point. A total of 6,000 requests per minute averages 100 RPS, but that minute may contain 20 seconds of overload followed by silence. Average intensity does not describe the arrival pattern. Account for retries separately: rising RPS may reflect repeated attempts rather than new user tasks.
Throughput: completed work
Throughput is the rate of work in selected units: requests, messages, megabytes, or orders per unit of time. Always state the unit and definition of success. One hundred responses per second, half of them errors, are not equivalent to one hundred successful orders.
Distinguish overall throughput from useful throughput. If checkout contains five API requests, count completed orders by business outcome rather than dividing the HTTP counter by five: some scenarios may fail midway. Likewise, accepting a job and successfully completing it are separate events in an asynchronous process.
Latency and measurement boundaries
Latency is used in different ways. Clarify the start and end: time to first byte, time to complete response, time from clicking to seeing the result, or time from queue insertion to processing. A server's 100 ms does not automatically include network transit, connection waiting, and UI rendering.
Read tool documentation for metric names too. For example, k6 http_req_duration combines sending, waiting for a response, and receiving; initial connection establishment is measured separately. Do not compare it without explanation to user journey time or a server metric with different boundaries.
Percentiles: what the average hides
p95 is a value around which 95% of observations in the selected sample fall at or below; the remaining tail may be much slower. Calculation method and sample size matter for precision. p50 describes the middle of the distribution, while p99 captures rarer delays.
Imagine 100 responses: 95 take 100 ms and five take 3 seconds. The average is 245 ms, yet five users waited a long time. Using nearest-rank, p95 is 100 ms and p99 is 3 seconds; an interpolation method may produce a different boundary. State the tool and analyze the distribution alongside observation counts.
Why percentiles cannot be averaged
Averaging two servers' p95 values does not produce the overall p95. Servers may handle different request counts and have entirely different distributions. Likewise, averaging per-minute percentiles does not yield a percentile for the whole test.
Combining data requires compatible raw observations or a suitable aggregatable histogram from which a quantile can be calculated. Prometheus explains the distinction between histograms and precalculated quantiles in summaries. Histogram results may be estimates: accuracy depends on how the distribution is represented. Avoid reporting false precision to the microsecond if the method cannot provide it.
Errors, queues, and concurrency
Examine response speed alongside error, timeout, cancellation, and incomplete-operation rates. A system can quickly reject every new request, improving overall latency while ceasing useful work. Separating successful and unsuccessful responses makes this visible.
Observe active request counts and queues. With the same incoming flow, longer service time often causes work to accumulate. Virtual users, active HTTP requests, and real users are different quantities. In a closed model, a slowdown can reduce generated traffic and conceal overload; account for this when interpreting results.
Practical example: an export queue
Over five minutes, the generator starts 3,000 jobs and the server accepts all of them, but produces only 2,400 files successfully. The remaining 600 await processing. Average arrival intensity is 10 jobs per second; useful completion throughput is 8 files per second during this window. If the queue was initially empty and there were no other outcomes, it grew by 600 jobs.
The acceptance API may respond with p95 of 150 ms, but this does not mean exports finish in 150 ms. Measure acceptance time, queue waiting, and time until a correct file is available separately. An illustrative criterion such as "99% of exports are ready within 30 seconds" must be checked across each job's lifecycle, including jobs that miss the deadline.
Assembling run results
Before testing, define successful events and what belongs in the denominator. Align client and server time windows, separate warmup, and preserve scenario identifiers. Show metrics by operation: search and export should not be indiscriminately combined into one distribution.
Report target and achieved intensity, started and completed operation counts, errors, p50/p95/p99, units, and measurement methods. Add time series: a brief failure can disappear within a good hourly aggregate. If the generator skipped starts because of its own limits, identify that limitation in the test.
Key takeaways for QA
RPS describes request flow, throughput describes completed work, latency measures time within defined boundaries, and percentiles describe observation distributions. Use them alongside errors and queues. Check definitions and aggregation methods: careful calculation matters more than an attractive number in a report.