JMeter Distributed Load Testing — Master + Slaves Setup (2026)

Last updated 2026-07-20 · 11 min read · By Avinash Kamble, reviewed by Priyanka G.

A single JMeter JVM caps out around 1,000-1,500 threads on a beefy 8-core box. Past that, GC pauses and thread contention distort your numbers before your app breaks. Distributed mode fixes this — one master, N slaves, one aggregated report. This guide covers the RMI setup, the SSL gotcha, and when to skip JMeter entirely and use k6 instead.

Key takeaways

• The single-JVM ceiling (and how to know you've hit it).
• Master + slave setup on AWS EC2 or Kubernetes.
• The RMI SSL cert step everyone misses.
• A worked 50k-user test with results.

You are ceiling-bound when: (a) CPU on the load generator exceeds 70%, (b) response times start scaling with thread count on the client not the server, (c) GC pauses show in jstat -gc. At that point, extra threads generate noise, not load.

# On each slave
./jmeter-server -Djava.rmi.server.hostname=<slave-ip>

# On master — list all slaves
./jmeter -n -t test.jmx -R slave1,slave2,slave3 -l results.jtl

Ports required open between master and slaves: 1099 (RMI registry), 50000 (server), 60000 (client callback). Firewall these off from the public internet.

JMeter 5.0+ enables RMI SSL by default. Generate a keystore with create-rmi-keystore.sh and copy it to every slave, or disable SSL (only in private VPC) with server.rmi.ssl.disable=true in jmeter.properties. Skip this and you get a cryptic "Connection refused" that costs hours.

For elastic load, use the jmeter-kubernetes chart — master + N slave pods, results streamed to InfluxDB + Grafana. If you are green-field, consider k6 — it is JavaScript-native, single-binary, and scales linearly without RMI. For the API-testing complement, see our REST Assured guide.