Core metrics explained
Every MaxoPerf run-detail page presents the same set of core metrics. Before you can interpret a result, you need a clear definition of each metric and a mental model of how they relate to each other. This page covers the five you will see 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.
Why a distribution matters: if you only look at the average, a single slow request in a fast run will barely move the needle. But if you look at p99, that outlier shows up clearly. Real users experience the tail — not the average. See Latency percentiles deep dive for a full treatment 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 (which 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 is also used to describe 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; the measured RPS in the result is the
actual. The gap between them is meaningful — 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 a breakdown by status code, endpoint label, and sample response bodies.
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 that are in flight simultaneously — requests that have been sent but 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 latency and throughput must be read together — a concurrency spike often precedes a latency spike.
MaxoPerf does not plot raw concurrency directly 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, near-zero error rate. When the pipe gets too full, latency climbs, error rate rises, and throughput may actually 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 just 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 mask 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.