Core metrics explained
Every MaxoPerf run-detail page shows the same core metrics. To interpret a result, you need a clear definition of each metric and a picture of how they relate to each other. This page covers the five that appear on every Overview tab.
Latency
Section titled “Latency”Latency is the time between a virtual user sending a request and receiving the complete response. In MaxoPerf, latency is always reported as a distribution, not a single number. The Overview tab shows time-series lines for p50, p90, p95, and p99 latency.
Latency is measured in milliseconds. A p95 latency of 320 ms means 95% of requests completed in under 320 ms. The slowest 5% took longer.
The distribution matters because a single slow request in a fast run barely changes the average. At p99, that outlier shows up clearly. Real users feel the tail, not the average. See Latency percentiles deep dive for the full explanation of why averages mislead.
Throughput (RPS)
Section titled “Throughput (RPS)”Throughput measures how many requests per second (RPS) the system is actually completing. MaxoPerf shows throughput as a time-series line on the Overview tab.
Throughput is the output of the system, not the input (the input is the load you asked for). If you configured 100 virtual users but throughput is only 20 RPS, the system is a bottleneck. If throughput matches or exceeds your target load, the system is keeping up.
The relationship between throughput and latency is diagnostic:
- Throughput rises, latency flat → system is scaling.
- Throughput plateaus, latency climbs → capacity ceiling reached.
- Throughput drops, error rate rises → system is rejecting requests.
Requests per second (RPS)
Section titled “Requests per second (RPS)”RPS is the same as throughput (requests completed per second), but the term also describes the target arrival rate in open workload models. In MaxoPerf, the Overview tab label says “Throughput (RPS)”, which is the completed rate.
When you configure a test with an arrival-rate model (Taurus concurrency + throughput or k6
constant-arrival-rate), the configured RPS is the intent and the measured RPS in the result is the
actual. The gap between them tells you something. If actual RPS is lower than configured, the system
couldn’t keep up. See Open vs closed workload models
for when to use arrival-rate models.
Error rate
Section titled “Error rate”Error rate is the percentage of requests that returned an error response. In MaxoPerf, an error is any response that the test engine (Taurus/JMeter/k6) classifies as a failure, typically HTTP 4xx or 5xx status codes, connection timeouts, or assertion failures.
The Overview tab shows error rate as a percentage over time. The Errors tab (accessible from the run-detail tab bar) shows errors grouped by category and message, per request label, with captured request and response samples.
Interpreting error rate:
| Error rate | Interpretation |
|---|---|
| 0% | All requests completed successfully (assuming assertions are meaningful). |
| < 1% | Usually acceptable depending on SLO. Investigate the specific errors. |
| 1–5% | Worth investigating; may signal a real capacity or configuration issue. |
| > 5% | The system is clearly struggling or misconfigured; address before drawing conclusions. |
A 0% error rate does not mean the test is valid. It means no requests returned an error code. An empty response or a mock upstream returning 200 can produce 0% errors on a broken system.
Concurrency
Section titled “Concurrency”Concurrency is the number of requests in flight at the same time: requests that have been sent but have not yet received a response. It differs from virtual users (VUs):
- A virtual user is a simulated user running a scenario. A VU may pause for think time between requests.
- Concurrency is the instantaneous count of outstanding requests. It depends on VU count, think time, and latency.
At high latency, concurrency climbs even with the same VU count, because each request takes longer to complete and more requests pile up. This is one reason to read latency and throughput together: a concurrency spike often comes before a latency spike.
MaxoPerf does not plot raw concurrency on the Overview tab. You read it indirectly. If throughput is constant but latency climbs, concurrency is increasing because responses are slowing down.
How the metrics relate
Section titled “How the metrics relate”Think of your system as a pipe:
- VU count = how many users are trying to use the pipe.
- Throughput (RPS) = how much water is flowing through.
- Latency = how long a single drop takes to traverse.
- Error rate = how much water is spilling before it exits.
- Concurrency = how full the pipe is at any instant.
A healthy system under sustainable load shows steady or rising throughput, flat latency, and a near-zero error rate. When the pipe gets too full, latency climbs, error rate rises, and throughput may drop, because the system starts rejecting or timing out requests.
Do / don’t
Section titled “Do / don’t”| Do | Don’t |
|---|---|
| Read latency as a distribution (p50/p95/p99), not only the average. | Report “average latency” to stakeholders. It hides tail behavior. |
| Compare throughput to the configured load profile to verify the run was valid. | Ignore the gap between configured and actual RPS. |
| Investigate any non-zero error rate before drawing conclusions from latency. | Treat a low error rate as “close enough” without checking what the errors are. |
| Look at latency and throughput together. One without the other gives an incomplete picture. | Use only error rate as a pass/fail criterion. A 0% error rate can still hide slow responses. |
Where to go next
Section titled “Where to go next”- Latency percentiles deep dive: why p50/p95/p99 matter and how to read the percentile chart.
- Anatomy of a load test result: a full tour of the MaxoPerf run-detail page.
- Read run results and logs: the recommended order for reading a finished result.
- Baselines, SLOs, and error budgets: how to define what “good” looks like for each metric.