HTML Dashboard Reports and Performance Result Interpretation: Configuration, Design Patterns, and Trade-Offs

1. Mandatory path remains local/free

2. Which percentiles should you report?

JMeter's dashboard exposes three configurable percentile slots, default p90/p95/p99. Choose percentiles that match:

• the service objective/regression policy;
• sample volume—p99 from 20 samples is unstable and low-resolution;
• traffic criticality—high-tail objectives may require far more samples;
• comparison consistency—the same percentile policy across baseline/candidate runs.

A useful dashboard may report p50 (via raw analysis) plus p90/p95/p99, but do not turn every percentile into a release gate.

3. APDEX versus explicit SLOs

Use APDEX as a summary, not a substitute for latency/error/throughput objectives.

4. Per-transaction APDEX thresholds

If Search and Checkout have different objectives, current JMeter supports:

jmeter.reportgenerator.apdex_per_transaction=Catalog:75|200;\
Checkout:100|300

Names/regex must remain stable. Document the thresholds beside the report because a score cannot be interpreted without them.

5. Transaction-controller labels versus low-level sampler labels

A business journey such as “Checkout Journey” can be easier to report than five internal HTTP requests. Transaction Controller can add a transaction sample, but then label/count semantics must be explicit.

Current dashboard behavior varies by graph: request summary/hits/bytes/codes and some overview graphs ignore/exclude Transaction Controller samples, while response-time, latency, transactions/sec, distribution and percentile graphs may include them. The JMeter dashboard documentation recommends the default Generate parent sample unchecked for accurate reporting in normal transaction-controller usage.

6. Avoid double-counting parent and children

If a transaction sample and its child samplers all exist in JTL, “total samples” is not automatically “business transactions.” Define:

• request rate: low-level protocol samplers only;
• business transaction rate: transaction/controller label only;
• latency: whichever layer your SLO is defined on.

Never add parent + children to produce a business throughput count unless you intentionally want mixed units.

7. Full run versus time-window filtering

8. Sample filter versus series filter

Example pre-calculation source filter:

jmeter.reportgenerator.sample_filter=^(Catalog|Checkout)$

Example HTML display filter:

jmeter.reportgenerator.exporter.html.series_filter=^(Catalog|Checkout)(-success|-failure)?$
jmeter.reportgenerator.exporter.html.filters_only_sample_series=true

The first changes the data used for calculations. The second primarily changes what series/rows are displayed after calculations. Record which was used.

9. Time-series granularity

The current default over-time granularity is 60 seconds. That is reasonable for longer tests but would collapse the short local Chapter 23 run. The lab uses 2000 ms; current JMeter warns the granularity must remain above 1000 ms or throughput graphs become incorrect.

Do not use tiny buckets to create noisy “precision.” Choose a bucket size that produces enough samples per bucket for your workload duration/rate.

10. HTML dashboard versus time-series backend

Chapter 24 will implement the backend path; Chapter 23 remains fully local with HTML.

11. Labels/error tables can leak data

Dynamic labels, response messages and assertion failure messages can contain identifiers or sensitive values. Keep labels stable and non-sensitive. Treat dashboard directories as derived performance evidence with the same access/retention review as their source JTL.

12. Layer boundaries

13. Worked scenario

A 30-minute test has 5-minute ramp, 20-minute steady state and 5-minute recovery. Release SLO is Checkout p95≤250 ms and errors≤1% during steady state.

• Retain full raw JTL and full dashboard for chronology.
• Create a second explicitly filtered 20-minute report using predetermined start_date/end_date.
• Gate Checkout p95/error from raw rows in that window.
• Report APDEX only as an additional summary with published thresholds.
• Compare generator/SUT resource telemetry for the same window.

14. Decision table

15. Evidence contract for comparable reports

Every dashboard comparison must retain the source CSV JTL, the matching jmeter.log, the exact report properties/filter/window configuration, workload manifest, JMX/property hashes, generator resource evidence, and independent target telemetry. The HTML directory is derived evidence and must never be the only retained artifact.

16. Configured versus achieved load

Dashboard throughput/errors/latency describe completed recorded samples, not configured intent. Before a regression claim, verify expected sample count/rate, generator headroom, target event count and the exact filter/window. A candidate run that completed fewer requests because the generator saturated is not comparable merely because its p95 looks lower.

Knowledge check

Official references and version notes

• JMeter User Manual — Generating Dashboard Report — required CSV fields, APDEX, statistics/percentiles, errors, graphs, filters, date windows, granularity, -g, -e, -o, and output-folder rules.
• JMeter Getting Started — CLI/load analysis — GUI authoring/debugging, CLI load execution, CSV/XML results and HTML analysis.
• JMeter Listeners / Result files — sample-log fields and raw-result interpretation.
• Component Reference — Transaction Controller — parent/additional transaction samples and reporting semantics.
• JMeter Properties Reference — report/save-service configuration and defaults.
• Apache JMeter downloads — current stable release and Java requirement.