You have run your distributed test across 5 machines. Now you have results. But how do they come together? Understanding result aggregation is crucial because misinterpreting distributed results is one of the most common mistakes in performance testing.
During a distributed test, each worker streams its sample results back to the master in near-real-time via the RMI connection. The master collects all results and writes them to a single JTL file. From the results perspective, it looks like all samples came from one machine -- except you can identify which worker generated each sample if you enable the right settings.
Here is a subtle issue. When 5 workers are generating thousands of requests per second, all streaming results back to the master, the master network interface can become a bottleneck. Each sample result contains timestamp, response time, response code, thread name, bytes sent/received, and more. Multiply that by 10,000 samples per second, and you are pushing significant data over the wire.
# --- Reduce result data sent over network ---
# Save only essential fields (reduces network overhead)
jmeter.save.saveservice.output_format=csv
# Disable saving response data (huge bandwidth saver)
jmeter.save.saveservice.response_data=false
jmeter.save.saveservice.response_data.on_error=false
# Disable saving request headers/body
jmeter.save.saveservice.request_headers=false
jmeter.save.saveservice.samplerData=false
# Disable saving response headers
jmeter.save.saveservice.response_headers=false
# Use Stripped mode for even less data
# mode=Stripped sends only essential metrics
mode=Standard
# Use StrippedBatch for best performance
# Batches results and sends them periodically instead of per-sample
mode=StrippedBatch
# Batch settings (when using batch modes)
num_sample_threshold=100
time_threshold=60000Sometimes you need to know which worker generated which results. Maybe one worker is showing higher response times because it is on a different network segment. JMeter can prefix the thread name with the worker hostname.
# Prefix sample labels with worker hostname
# Results will show: worker1-Thread Group 1-1, worker2-Thread Group 1-1, etc.
sample_sender_strip_also_on_prefix=true
# Or set a custom prefix for this worker
# sample_sender_client_configured_prefix=Worker1-For very high-throughput tests, you can tell each worker to save results locally instead of streaming them back to the master. After the test, you collect and merge the files. This eliminates the result-streaming bottleneck but adds a manual merge step.
# In jmeter.properties on each worker:
# Use the local saving mode (results not sent to master)
mode=Standard
# Add a Simple Data Writer listener in your test plan
# pointing to a local file path on each worker:
# /opt/jmeter/results/worker_${__machineName()}_results.jtl# Collect results from all workers
for host in worker1 worker2 worker3 worker4 worker5; do
scp user@$host:/opt/jmeter/results/*.jtl ./collected/
done
# Merge all JTL files (they are CSV, so just concatenate)
# Keep header from first file, skip headers from the rest
head -1 collected/worker1_results.jtl > merged_results.jtl
for f in collected/*.jtl; do
tail -n +2 "$f" >> merged_results.jtl
done
# Sort by timestamp for chronological order
head -1 merged_results.jtl > sorted_results.jtl
tail -n +2 merged_results.jtl | sort -t, -k1 -n >> sorted_results.jtl
# Generate HTML report from merged results
jmeter -g sorted_results.jtl -o /results/html_report/For tests generating more than 5,000 samples per second across all workers, consider local result saving with post-test merge. The network overhead of streaming results can actually affect test accuracy by consuming bandwidth that should go to the test traffic.
Key Point: Results stream from workers to master via RMI. For high-throughput tests, optimize by disabling response data saving, using batch modes, or saving results locally on each worker and merging afterward.
Key Point: Master aggregates results from all workers into one JTL file. For high-throughput tests, save results locally on workers and merge afterward.