Aggregate Report: Percentiles and Throughput
Aggregate Report groups samples by label like Summary Report, but adds the columns that matter most for real SLA analysis: 90% Line, 95% Line, and 99% Line, representing the response time under which that percentage of requests completed. This matters because Average can hide a long tail of slow requests — a label with an average of 300ms could still have a 99th percentile of 4 seconds if a small fraction of requests are severely degraded, and that tail is often exactly what real users experience as 'the site feels slow sometimes.' Alongside percentiles, it reports Throughput (requests/second the server actually sustained, not the rate JMeter attempted to send) and Error %, making it the standard listener for post-run performance sign-off.
Cricket analogy: Relying on average response time is like judging a bowler purely by economy rate across a whole innings without checking if a couple of overs conceded 20 runs each — the 99th percentile is like flagging those specific expensive overs that the average smooths over.
Graph Results and Other Visualizations
The Graph Results listener plots response time as a live line chart during a GUI-mode run, and Response Time Graph does something similar but grouped over configurable time intervals. Both are useful for a quick visual sense of trend during small debugging runs, but they share the same fundamental problem as View Results Tree: they retain data points in memory and render continuously, so they become a bottleneck and a source of skewed results the moment you scale thread count up for a genuine load test. For serious visualization at scale, the JMeter community and Apache's own documentation steer users toward exporting .jtl results and feeding them into purpose-built tools — Grafana backed by InfluxDB via the Backend Listener, or JMeter's own built-in HTML Dashboard Report generator — rather than trusting any in-GUI graph listener for a high-concurrency run.
Cricket analogy: Relying on Graph Results at scale is like a scorer trying to hand-draw a run-rate worm chart in real time during a T20 game with a required rate of 12 an over — by the time you've drawn one over's point, three more deliveries have already happened.
Generating HTML Dashboard Reports from CLI
JMeter ships a built-in HTML Dashboard Report generator that turns a .jtl results file into a rich, static report with response time percentile graphs, throughput-over-time charts, and APDEX scoring, without needing any GUI listener active during the actual run. You can generate it either inline during a non-GUI test run using the -e -o flags, or afterward from an existing results file using -g. This is the standard approach for CI/CD pipelines: run the load test headless, produce the .jtl, generate the dashboard as a build artifact, and archive or publish it so the team can review performance trends without ever opening JMeter's GUI.
Cricket analogy: Generating a post-match HTML dashboard is like producing the full statistical scorecard and Manhattan chart after the game ends rather than trying to compile it ball-by-ball live — the analysis happens from the recorded data, not during play.
# Run the test headless and generate the HTML dashboard report in one step
jmeter -n -t checkout_test.jmx -l results.jtl -e -o report_output/
# Or generate the dashboard afterward from an existing .jtl file
jmeter -g results.jtl -o report_output/
# report_output/index.html contains APDEX, response time percentiles,
# throughput-over-time, and active-threads-over-time chartsThe -o output directory must not already exist (or must be empty) when using -e -o in the same run — JMeter will refuse to overwrite a non-empty directory, which is a common CI pipeline gotcha; clean the directory before each run.
Aggregate Report's percentile values are calculated only from the samples present in that specific run/listener instance. If you merge multiple .jtl files or filter samples externally before loading them, percentiles must be recalculated from the full merged dataset — you cannot average percentiles from separate partial reports.
- Aggregate Report adds 90%/95%/99% Line percentile columns to the per-label metrics that Summary Report already shows.
- Percentiles reveal the slow-request tail that an Average figure can hide entirely.
- Graph Results and Response Time Graph are live GUI charts, useful only for small-scale debugging, not real load tests.
- For scaled visualization, export .jtl data to Grafana/InfluxDB via the Backend Listener or use JMeter's built-in HTML Dashboard Report.
- The -e -o flags generate the dashboard report inline during a non-GUI run; -g generates it afterward from an existing .jtl.
- The dashboard's output directory must be empty or nonexistent, or JMeter will refuse to write to it.
- Percentiles cannot be averaged across separate partial reports — recompute from the full merged sample set.
Practice what you learned
1. What does the '95% Line' column in Aggregate Report actually represent?
2. Why is it risky to rely solely on Average response time for performance sign-off?
3. Which JMeter CLI flag combination generates the HTML Dashboard Report inline during a non-GUI test run?
4. Why should Graph Results or Response Time Graph generally be avoided during a genuine large-scale load test?
Was this page helpful?
Previous
Listeners: View Results Tree and Summary Report
Next
Logic Controllers: If, Loop, and Transaction
You May Also Like
Listeners: View Results Tree and Summary Report
Understand JMeter's two most-used listeners — View Results Tree for per-sample debugging and Summary Report for aggregate metrics — and how to use each without crippling your test's performance.
Duration and Size Assertions
Use JMeter's Duration Assertion and Size Assertion elements to fail samples that violate response-time SLAs or return an unexpected payload size, catching performance and correctness regressions in the same test run.
Response Assertions
Learn how JMeter's Response Assertion element validates sample responses against text, regex, and status-code patterns so failures are caught automatically instead of hiding in raw response data.