Load Test Results Analyzer (JMeter, k6, Locust)

About the Load Test Results Analyzer (JMeter, k6, Locust)

Open the results of a load test and get the report you would otherwise build in a spreadsheet: every label’s samples, error rate, throughput and response times (minimum, mean, median, p90, p95, p99 and maximum), Apdex for the threshold you choose, SLA rules such as “p95 under 500 ms and errors under 1 %” with a pass or fail for every label, the errors grouped by response code and message, and charts over time of the percentiles, throughput, errors and active users. Add a baseline run and each label is compared with it, with the regressions beyond your threshold flagged.

It reads JMeter results (the .jtl files JMeter writes, as CSV or XML), k6’s JSON output (k6 run --out json) and its end-of-test summaries, Locust’s CSV files (stats, history, failures and exceptions) and any CSV of timestamps, labels and response times. Files of a gigabyte and more are read in a background worker as a stream, and every response time is kept, so the percentiles are exact (above 20 million samples they become estimates, marked as such).

Nothing is uploaded. Without a pass the report is a free preview: the overall summary, every SLA result and the first rows of each table. The charts, the comparison, every label and the HTML, PDF and CSV exports unlock with a Premium pass.

Common uses

• Reading a JMeter, k6 or Locust run without opening JMeter’s GUI, a dashboard or a spreadsheet.
• Checking a release against its performance SLA before it ships, and seeing which endpoint fails it.
• Comparing a run with the last good one to catch a regression in one endpoint that the overall figures hide.
• Sending stakeholders a one-file HTML or PDF report with the charts and tables.

Getting the files out of each tool

• JMeter: jmeter -n -t plan.jmx -l results.jtl writes a CSV with a header by default; an XML .jtl works too. The columns are listed in JMeter’s manual (CSV and XML log formats); a CSV written without field names is read in JMeter’s default column order. In XML, embedded resources are sub-samples: they count as samples of their own only when you tick that option.
• k6: k6 run --out json=results.json script.js writes one JSON object a line (k6 JSON output). Each http_req_duration point is a request, labelled by its name tag (k6 sets it to the URL unless the script names the request), and failed when expected_response is false. vus gives the active users and checks the checks. An end-of-test summary (from handleSummary or --summary-export) gives k6’s own totals only.
• Locust: --csv=run writes run_stats.csv, run_stats_history.csv, run_failures.csv and run_exceptions.csv (Locust configuration); open them together. Locust keeps statistics, not single requests: its percentiles are its own (it rounds response times above 100 ms to about two significant figures), and Apdex cannot be worked out.
• Any other tool: a CSV with a response-time column in milliseconds, and optionally a label, a timestamp, a success flag, a status code and an error message.

How the figures are worked out

• Percentiles are exact, by the nearest-rank method: p95 is the smallest response time that at least 95 % of the samples are at or below. Tools differ in how they choose between two neighbouring samples, so a value can differ from another report’s by one sample’s worth.
• Throughput is the samples divided by the time from the first sample’s start to the last sample’s end, as JMeter defines it (JMeter glossary); KB/s counts 1,024 bytes a KB.
• Apdex for a threshold T = (satisfied + tolerating ÷ 2) ÷ total samples, where a sample is satisfied at or below T, tolerating above T up to F = 4T and frustrated above F, and failed samples count as frustrated. It is shown as the specification asks, with two decimals and T in seconds — 0.85 [0.5] — with an asterisk under 100 samples, and rated Excellent (0.94 and above), Good (0.85), Fair (0.70), Poor (0.50) or Unacceptable (Apdex Technical Specification).
• Charts over time group the samples into intervals (one second, doubled until the test fits in a few hundred points); the percentiles of each interval come from a histogram with bins about 2 % wide.

SLA rules and regressions

Each rule compares one figure — a percentile, the mean, the maximum, the error rate, throughput or Apdex — with a value, for every label or for one label by name. A label passes when every rule that applies to it passes; the run passes when every label and the overall figures pass. In a comparison, a time or the error rate is a regression when it is more than your threshold higher than in the baseline, and throughput when it is more than the threshold lower; a figure that was zero in the baseline and is not now always counts.

Limitations

• The response times are those the load tool measured on its machine: a client that was overloaded itself makes every figure worse.
• Above 20 million samples the percentiles and Apdex are t-digest estimates, marked “≈”; the counts, the error rate and throughput stay exact.
• A k6 summary and Locust’s files hold their tools’ own figures: no charts from a k6 summary, no Apdex from either.
• Files are read in your browser: a run of several gigabytes needs a desktop with plenty of memory to spare.
• Times written without a time zone (a formatted JMeter timestamp, a CSV of your own) are read in the zone you choose; epoch timestamps and k6’s times are exact.

Privacy

On this device: nothing is sent

Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.