Uzak Sunucularla Dağıtık Sınama

A single JMeter instance is bounded by its CPU, memory, and network. To simulate thousands of users you spread the load across several machines using distributed testing.

In distributed mode one machine is the master (controller) that holds the test plan, and several slaves (servers) actually generate the load.

Each remote machine runs the JMeter server agent, which listens for instructions from the master.

List the slave IPs in the master's jmeter.properties so it knows where to send the plan.

Run the test in non-GUI mode and tell the master to drive all remote servers.

The master sends a copy of the test plan to each slave. So a 100-user Thread Group on 3 slaves generates 300 users total — plan thread counts per machine, not in aggregate.

Master and slaves communicate over RMI ports. Open those ports and ensure all machines can reach each other, ideally on a low-latency private network.

CSV data files referenced by the plan must exist on every slave, or be split per slave so users do not overlap. The master does not auto-copy them.

Each slave streams results back to the master, which aggregates them into a single results file and report for the whole run.

The master only coordinates and aggregates, so keep heavy listeners off during the run. Generate the dashboard report afterward from the JTL file.

Use distributed testing when:

• One machine maxes out before your target load
• You need to simulate geographically spread users
• You require very high concurrency

You learned distributed load testing:

• A master coordinates several load-generating slaves
• Run jmeter-server on slaves, list them in remote_hosts
• Launch with -r; the plan is copied to every slave
• Distribute data files and let the master aggregate results