Now that we know why we need multiple machines, let us understand how JMeter organizes them. JMeter uses a master-slave architecture (officially called controller-worker in recent versions, but everyone in the industry still says master-slave, so we will use both terms). Think of it like a call center manager and a team of agents.
Imagine you are managing a customer support team. You (the master/controller) have a script that every agent must follow when handling calls. You distribute this script to all agents (slaves/workers). Each agent independently handles their batch of calls using the same script. At the end of the day, every agent sends their call logs back to you, and you compile the final report. You do not make any calls yourself -- you just coordinate.
That is exactly how JMeter distributed testing works. The master sends the test plan, workers execute it, and results flow back to the master.
| Component | Role | Runs Test Plan? | Generates Load? | Key Process |
|---|---|---|---|---|
| Master (Controller) | Distributes test plan, collects and aggregates results | Sends to workers | No (by default) | jmeter CLI with -r or -R flag |
| Worker (Slave) | Executes the test plan, sends results to master | Receives from master | Yes | jmeter-server process |
| Target System | The application being tested | N/A | N/A | Your web app, API, database |
Under the hood, JMeter uses Java RMI (Remote Method Invocation) for communication between master and workers. Think of RMI as a phone line between the manager and agents. The master "calls" each worker to say "here is your test plan, start executing." Workers "call back" the master with results as they come in.
RMI uses TCP connections. By default, the initial connection happens on port 1099 (the RMI registry port). After the initial handshake, RMI may use additional dynamic ports -- which is where firewall headaches begin (we will solve this later).
This is a critical gotcha that has burned many testers. The master only sends the JMX test plan file. It does NOT send:
The number one distributed testing failure: "My CSV data file is not found on the worker." JMeter only sends the JMX. Every external resource must be manually deployed to every worker machine at the correct path. Use the same absolute path across all machines, or use relative paths with the same directory structure.
Here is another common mistake. If your test plan says "Thread Group: 500 threads" and you have 4 worker machines, you get 500 x 4 = 2,000 total threads. Not 500 total. Each worker independently creates the full thread count specified in the test plan. If you want 2,000 total users across 4 machines, set your thread count to 500.
| Thread Count in JMX | Number of Workers | Total Virtual Users | Common Mistake |
|---|---|---|---|
| 100 | 3 | 300 | Expecting 100 total instead of 300 |
| 500 | 5 | 2,500 | Setting 2,500 in JMX and getting 12,500 |
| 1,000 | 10 | 10,000 | Forgetting to divide desired total by worker count |
| 200 | 1 (no distribution) | 200 | Running locally generates exactly what you set |
Formula: Threads in JMX = Desired Total Users / Number of Workers. If you want 10,000 users across 5 workers, set thread count to 2,000 in your test plan.
Q: Explain the JMeter master-slave architecture. What role does each component play?
A: JMeter distributed testing uses a controller-worker (master-slave) model. The master machine runs the JMeter CLI with the -r flag and is responsible for distributing the JMX test plan to all configured worker machines, coordinating test start/stop, and aggregating results. It does NOT generate load itself by default. Each worker machine runs the jmeter-server process, receives the test plan from the master, independently executes the full thread count, and streams results back to the master via Java RMI. Important details: (1) thread count is per worker -- 100 threads x 4 workers = 400 total users; (2) only the JMX file is sent -- CSV files, plugins, and external resources must be manually deployed to every worker; (3) communication uses RMI over TCP, default port 1099; (4) all machines must run the same JMeter version.
Key Point: The master sends only the JMX test plan. Threads multiply across workers. CSV files, plugins, and external resources must be deployed to every worker machine manually.
Key Point: JMeter uses master-slave (controller-worker) architecture. Master distributes the test plan and collects results. Workers generate the actual load.