Metrics and results glossary

This page covers the key numbers in a load test result. To make good release decisions from test data, you first need to know what each metric measures and where it can mislead you.

---

Latency

Latency is the time from a client sending a request to receiving the last byte of the response. A load test measures it per request, then aggregates it across the run as a distribution, not only a mean.

In MaxoPerf: the run-detail Overview tab shows latency as a time-series chart split by label (endpoint or transaction). You can switch between p50, p90, p95, and p99 views.

Tip

Always look at latency by label. One slow endpoint can dominate a high aggregate latency and hide that everything else is fast.

---

Percentiles

Percentiles describe the distribution of a metric. The p95 value means 95 percent of observations were at or below that value. The p99 value covers 99 percent.

Why percentiles matter more than the mean: a few very slow requests can hurt real users while the arithmetic mean still looks healthy. Percentiles show those slow outliers.

See the canonical card for full detail: p95 and p99 latency in the SEO Glossary.

In MaxoPerf: the charts panel lets you select p50 / p90 / p95 / p99 for each label independently. You can write failure criteria against any percentile (e.g. p99 < 2000ms).

Caution

Do not compare p99 from a 10-VU smoke test against p99 from a 500-VU release candidate. The sample sizes and system pressures are not comparable.

---

Mean response time

The mean response time (arithmetic average) is the sum of all response times divided by the number of requests. It is easy to compute and easy to misread. One very slow request adds a lot to the mean while it affects few users.

In MaxoPerf: the summary table shows the mean next to the percentiles. Use the mean as a sanity check, not a decision metric. Prefer p95 or p99 for release gates.

---

Throughput

Throughput is the work completed per unit of time. For HTTP load tests you usually express it as requests per second (RPS) or transactions per second (TPS). For data-intensive systems you can express it in bytes per second.

Higher throughput only helps if latency and error rate stay within acceptable bounds. A server that completes 5,000 RPS but returns 40% errors is not healthy.

See also: Requests per second (RPS) below.

---

Requests per second (RPS)

Requests per second is the rate at which requests complete during a test. It is the most common throughput metric for HTTP APIs and web services.

See the canonical card: Requests per second in the SEO Glossary.

In MaxoPerf: RPS appears in the Overview throughput chart. You can set an RPS-based target in the load profile (“constant request rate” mode) or read actual RPS from the results panel after a run.

Note

RPS is an output metric (what the system actually served). In some engines it is also an input target you configure. Say which one you mean when you discuss test results.

---

Error rate

Error rate is the percentage of requests that returned an error response (HTTP 4xx/5xx, connection failure, assertion failure, or engine-level error). You express it as a fraction: errors / total requests.

A zero error rate during a load test does not mean the system is healthy. Slow responses are not errors by default. Read error rate together with latency percentiles.

In MaxoPerf: the summary panel and the per-label breakdown show error rate. Failure criteria can fail the test when error rate exceeds a threshold (e.g. error rate > 1%).

---

Time to First Byte (TTFB)

Time to First Byte is the time from a client sending a request to the server sending the first byte of the response body. It stands in for server processing time before data transfer begins.

In MaxoPerf: the detailed results export includes TTFB as a per-label metric. High TTFB under load usually points to backend compute saturation, slow database queries, or upstream dependency latency, not network bandwidth.

---

Apdex

Apdex (Application Performance Index) is a standardized 0–1 score that buckets response times into three zones: satisfied (below a threshold T), tolerating (between T and 4T), and frustrated (above 4T). The score is:

Apdex = (satisfied + tolerating / 2) / total

A score of 1.0 is perfect. 0.0 means every request was frustrating. Teams typically pick T to match acceptable UX (e.g. 500 ms for an API).

In MaxoPerf: the summary view shows Apdex, and you can use it as a failure-criteria target. Set T in your test configuration to match your SLO.

---

Response time distribution

The response time distribution (sometimes called a histogram or frequency chart) shows how many requests fell into each response-time bucket. It shows the shape of your latency. A bimodal distribution (two humps) often means the test exercises two different code paths or two different backend behaviors.

In MaxoPerf: the distribution chart on the run-detail page shows whether latency is tight and unimodal (consistent) or spread out (variable). A long right tail explains why p99 is much higher than p50.

---

Label

A label is a name assigned to a request, transaction, or sampler in the test engine. Labels group requests by logical operation (e.g. checkout, product-search, login) so you can break results down per endpoint instead of seeing only an aggregate.

In MaxoPerf: you can filter or group every chart and table on the run-detail page by label. Label names that match your endpoint names or user journeys make results far easier to triage than numeric IDs or raw URLs.

Tip

Set labels in your test configuration before the first run. Renaming labels mid-test breaks comparisons across runs.

---

Where to go next

• Load modeling: VUs, concurrency, and how to set up a load profile.
• Foundations: core metrics explained: worked examples with screenshots.
• Foundations: latency percentiles in depth: why averages lie.