Metrics and results glossary

This page covers the key numbers you read in a load test result. Understanding what each metric measures — and where it can mislead you — is the first step to making good release decisions from test data.

---

Latency

Latency is the elapsed time between a client sending a request and receiving the last byte of the response. In load testing, it is measured per request and then aggregated across the run as distributions, not just 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. A high aggregate latency may be dominated by one slow endpoint, hiding the fact 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 small number of very slow requests can harm real users while the arithmetic mean still looks healthy. Percentiles surface those slow outliers.

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

In MaxoPerf: the charts panel lets you select p50 / p90 / p95 / p99 for each label independently. Failure criteria can be written 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 samples sizes and system pressures are incomparable.

---

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 but easy to misread: one very slow request adds a lot to the mean while affecting few users.

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

---

Throughput

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

Higher throughput is only good 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 — 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 — as well as a input target you configure in some engines. Distinguish which you mean when discussing 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). It is expressed 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. Combine error rate with latency percentiles to form a complete picture.

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

---

Time to First Byte (TTFB)

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

In MaxoPerf: TTFB is available as a per-label metric in the detailed results export. 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. The threshold T is typically chosen to represent acceptable UX (e.g. 500 ms for an API).

In MaxoPerf: Apdex is available in the summary view and can be used 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 reveals the shape of your latency — a bimodal distribution (two humps) often signals two different code paths or two different backend behaviors being exercised.

In MaxoPerf: the distribution chart on the run-detail page lets you see 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 that results can be broken down per endpoint instead of showing only an aggregate.

In MaxoPerf: every chart and table in the run-detail page can be filtered or grouped by label. Meaningful label names — aligned with 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 deep dive — why averages lie.