What should a useful load-test report measure?
A useful load-test report never presents QPS alone. It states the conditions, end-to-end business success, tail latency, errors and degradation, limiting resources and dependencies, capacity inflection, and recovery after load stops. Wavesteam writes “what evidence appeared under which conditions” so business, engineering, and operations can make a launch decision rather than interpret screenshots independently.
One thousand small reads, image uploads, and order creations are different workloads. P95 of 200 ms with no errors differs from the same latency while many transactions are rejected. Begin with the tested version and commit, topology and resources, data distribution, cache state, supplier treatment, time, and tool version. State operation mix, arrival or concurrency, think time, payload, ramp, duration, and peak so the test can be repeated.
When planning milestones, resources, and acceptance, also compare Why should a system undergo load and stress testing before launch? and How long does it take to build and launch a two-client software system?; the linked guidance adds context that should be considered in the same decision.
| Dimension | Record | Common error | Decision value |
|---|---|---|---|
| Business result | Completed orders, uploads, commands; rejects, duplicates | Treat HTTP 200 as business success | Did the user task complete? |
| Traffic and latency | Throughput, arrival/concurrency, P50/P95/P99, max | Average or isolated QPS | Where tail latency bends with load |
| Error and degradation | Timeout, 4xx/5xx, business error, retry, fallback | Count every limit as success or every expected reject as failure | Did failure match design? |
| Resource and dependency | CPU, memory, GC, I/O, pools, locks, queues, cache, upstream | CPU below 100% means no bottleneck | Which constraint caused the symptom? |
| Steady state and recovery | Backlog, water level, scaling, time to recover | Stop observing when load stops | Did leaks or unrecoverable accumulation remain? |
Grafana k6 distinguishes Counter, Gauge, Rate, and Trend in its metrics guidance and uses percentile and error conditions in thresholds. Wavesteam proposes thresholds before the run from confirmed peak, wait tolerance, failure impact, and budget. We do not ask the client to invent a technical SLO or select a passing number afterward.
Separate transport and business success per core scenario. Out of stock can be an expected business rejection; database timeout is a system failure. State whether latency is measured at generator, gateway, or server and whether it includes DNS, TLS, queueing, and suppliers. OpenTelemetry's HTTP metric conventions help correlate load generator and service observation.
View throughput with errors and latency: a system returning 500 immediately can show higher QPS after overload. Inspect individual cores, locks, pools, storage latency, GC pauses, consumer lag, and supplier quota rather than average CPU. Include time series and trace examples supporting the diagnosis.
The conclusion answers whether target load passed, where the first failure appeared, the evidenced limit, overload and degradation behavior, recovery time, and the recommendation: code optimization, resources, architecture, limits, or explicit risk acceptance. Capacity applies only to this environment and workload and does not convert directly into daily active users.
Each recommendation names priority, expected effect, cost, and retest. A replica may help reads but not write locks; more application instances can worsen a saturated database. Reuse scripts and data for comparison and retain raw results and configuration.
Wavesteam reports pass/fail, current capacity, bottleneck, option and cost, retest, and any launch stop. A tool's “Pass” is not the only release gate: accounts, backup and rollback, monitoring, severe defects, and business acceptance remain separate. The report turns capacity and failure from guesswork into reproducible, bounded evidence.