Understanding JMeter Distributed Testing Modes and Their Performance

When choosing a load‑testing tool, it is essential to consider its pressure capability; a single‑point tool cannot meet the demands of large clusters or high‑performance systems, so distributed support is required.

JMeter supports distributed testing by designating one machine as the client (controller) and multiple machines as servers; adding more client machines scales the pressure easily.

This article introduces several JMeter distributed modes and demonstrates how the DaBai platform optimizes JMeter's distributed execution.

Application Scenario

To use JMeter’s distributed service, run it in non‑GUI mode and use the -R parameter to specify the IP addresses of the server machines.

In a simple experiment with two machines, start JMeter‑Server on one machine:

The server starts and listens on the configured port; when the controller launches a task, the server begins executing it.

The highlighted IP indicates the server; this simple remote execution starts the test.

Common Questions

1. Where is performance data calculated, on the controller or the server?

Answer: The controller performs the calculation; each server sends request results to the controller for aggregation.

2. Does adding many servers guarantee efficient load testing?

Answer: Not necessarily; with many servers, the controller may become a bottleneck as it must collect and aggregate all results.

3. How can this issue be resolved?

Answer: The next section introduces different modes that can mitigate the bottleneck.

Application Modes

JMeter provides various data‑transfer modes to keep distributed testing optimal under different scenarios.

Standard mode

This is the conventional mode where each server sends the result of every request back to the client immediately.

Batch mode

As the name suggests, the server stores each request in a List<SampleEvent> sampleStore and sends the batch once a configured threshold is reached, reducing overhead.

Asynchronous mode

This mode uses a queue; when the queue reaches a certain size, an asynchronous worker processes and sends the requests to the controller.

We performed the same performance test on the three models using the DaBai platform to visualize the results.

Batch mode results:

Asynchronous mode results:

Even with the same script and hardware, the performance data differ significantly across modes. The DaBai platform shows the highest and most stable metrics for the standard mode.

In the next article we will detail the implementation of these three modes and the data‑collection methods used by DaBai.