Apache JMeter, a popular open-source performance testing tool, supports distributed testing to simulate large-scale loads by leveraging multiple systems. Distributed testing allows applications to scale load generation capabilities by utilizing multiple machines, enabling developers to simulate higher loads and gain more actionable performance insights.
Overview
What is Distributed Testing in Apache JMeter?
Distributed testing in Apache JMeter refers to the process of using multiple computer systems (nodes) to run a single test plan simultaneously. It leverages a client-server architecture.
Components of Distributed Testing in Apache JMeter
- Master (Controller Node)
- Worker Nodes
- Target
- Network Communication.
In this tutorial, we’ll go through what distributed testing is, how to perform distributed testing, and the challenges involved.
What is Distributed Testing in Apache JMeter?
Distributed testing in Apache JMeter refers to the process of using multiple computer systems (nodes) to run a single test plan simultaneously. It leverages a client-server architecture in which one JMeter instance acts as the Controller (Master), managing the test execution, while several other JMeter instances act as Workers, responsible for generating the actual load by sending requests to the Target application to stress test it.
Working of Distributed Testing Apache JMeter
When it comes to distributed testing in Apache JMeter, the Controller orchestrates the test by distributing the same test plan to all Workers. Each Worker executes the test plan independently, sending requests to the application under test.
The Workers then send their collected test results back to the Controller, which aggregates the data from all Workers into a single set of results. This setup allows for generating a higher load than would be possible from a single machine.
In summary, in JMeter distributed testing, one machine acts as the controller, while the others act as workers. The controller sends test scripts to the workers, which execute the tests in parallel, and send results back to the master for aggregation and analysis.
Why Do Distributed Testing in JMeter?
Some applications can experience high stress or increased load levels seasonally. For example, an ecommerce application experiences increased user traffic on Black Fridays. Developers have to be prepared for such occasions by testing the system’s ability to withstand stress.
To run load testing locally on Apache JMeter comes with a limitation as the number of users that can be tested is reduced. This is one reason why performing distributed testing is important.
Below are some more reasons why performing distributed testing in JMeter is necessary.
- Load Generation: Distributed testing allows for simulating a large number of concurrent users, which is necessary for realistic load testing scenarios, particularly for applications expecting high traffic during peak periods like Black Friday.
- Performance and Scalability: Distributed testing is essential for evaluating how an application scales under increasing load and identifying potential performance issues.
- Geolocation Testing: Distributed machines can be used to simulate users from different locations, and assess the impact of network latency on performance.
- Multiple JMeter clients: A single JMeter client can only handle a certain number of virtual users, limited by its CPU, memory, and network capabilities. Distributed testing erases these limitations by leveraging multiple machines to generate the required load.
- Complex Scenarios: Distributed testing enables the creation of more complex test scenarios with different virtual user profiles, allowing for more accurate simulation of real-world user behavior.
Working of Distributed Testing in JMeter: Architecture
In JMeter’s distributed testing architecture, a Client-Server or Master-Slave setup is used. The Master node, running the JMeter GUI, controls the test execution and receives results, while Slave nodes, running the JMeter Server, execute the test plan and send results back to the Master. This allows JMeter to simulate a large number of concurrent users by distributing the load across multiple machines.
Source: Apache JMeter
Master (Controller):
- This is the central controller; it can be run on GUI or CLI mode and it manages the test execution. It is the primary JMeter instance that controls the test
- It holds the master copy of the JMeter Test Plan (.jmx file).
- It distributes the test plan to Slave nodes.
- It initiates the start and stop commands for the test on all Workers simultaneously.
- Collects and aggregates results from all Slave nodes into a consolidated report or result file.
- It provides comprehensive insights into application performance.
Workers:
- These are JMeter instances running in a special server mode.
- Each Worker machine listens for incoming connections and commands from the Controller.
- Execute a copy of the test plan and generate a load on the target system.
- Workers send requests directly to the target application/server under test.
- They send test results back to the Controller over the network.
Target:
- This is the actual application or service undergoing the stress test.
Network Communication:
- Communication between the Master and Workers happen using Java Remote Method Invocation.
- The Controller must be able to reach each Worker on specific RMI ports (default registry port is 1099, but data ports are often dynamic unless configured)
- Workers must be able to send results back to the Controller
- Proper network configuration, including firewall rules allowing RMI traffic between the involved machines, is important.
Read More: Assert in Java
How to Run Distributed Testing in JMeter
To run distributed testing in JMeter, the following prerequisites must be in place:
Prerequisites
- There should be one master machine and one or more worker machines
- Have the same version of Java and JMeter installed on all machines.
- The firewalls on the systems are turned off, or the correct ports are opened.
- All the systems must be on the same subnet.
Steps to Perform Distributed Testing in JMeter
Here are the steps to perform distributed testing in JMeter:
Step 1: Worker Machines
On the worker nodes, navigate to the jmeter/bin directory and execute jmeter-server.baton Windows (jmeter-server on Unix/Linux).
Step 2: Controller Machine
- On the controller node acting as the console, open windows explorer and navigate to the jmeter/bin directory.
- Open jmeter.properties
- Edit the line remote_hosts=
- Add the IP addresses of the various worker machines. Example: remote_hosts=192.168.1.2,192.168.1.3
Step 3: Start JMeter
Launch JMeter using the appropriate startup script(.jar or .bat on Windows and .sh on Unix).
- Open any script with the .jmx extension,
- Go to Menu and select Run >> click Remote Start All (or Remote Start to select individual worker machines to run your test script).
Note: The remote_hosts= line consists of a list of comma separated IP addresses.
Performing JMeter Distributed Testing with Docker
Docker is an open-source project for automating the deployment of applications as portable, self-sufficient containers that can run on the cloud or on-premises. Docker containers can run anywhere- on your local machine, on-premise data center, in an external service provider, or in the cloud.
Running JMeter Distributed Testing with Docker simplifies environment setup and scalability.
The following steps illustrate how to perform JMeter Distributed Testing with Docker:
1. Pull the JMeter docker image using the command below:
docker pull justb4/jmeter:latest
2. Create a directory that contains the JMeter test plan files. Organize the collection of test plans in this directory.
3. Use the command below to run the JMeter test collection by mounting the test plan directory to the Docker container and specify the JMX file to execute:
docker run -it --rm -v /path/to/TEST_DIRECTORY:/mnt/jmeter -w /mnt/jmeter justb4/jmeter -n -t /mnt/jmeter/TEST_FILE.jmx
Challenges in JMeter Distributed Testing
JMeter Distributed Testing also comes with a few challenges like:
- Network Configuration: Firewalls, subnets, and port conflicts (especially with dynamic RMI ports) are common setup challenges. Therefore, configure firewalls to enable RMI ports and ensure all nodes are on the same subnet with static port mapping.
- Version and Configuration Consistency: Ensuring that all machines have the same JMeter and Java version and configuration is important for reliable distributed execution, but can be challenging to maintain. Utilize automation scripts or containerization (example: Docker) to maintain uniform JMeter and Java versions across all nodes.
- Network Latency: Network latency between the master and worker nodes can impact test execution time and results. Therefore, deploy master and worker nodes within the same local network or cloud region to reduce latency.
- Real-time Analytics: Monitoring and debugging JMeter’s distributed executions in real-time can be challenging and often requires external tools or plugins to provide insights into the execution status of each node.
- Resource management: Managing the resources of multiple machines can be complex, and efficient resource allocation is critical for optimal test execution.
- Remote Method Invocation( RMI) issues: RMI, used for communication between the master and worker nodes, can be complex to configure and may require firewalls to be opened or adjusted to allow traffic.
Conclusion
Apache JMeter’s distributed testing is useful for simulating real-life scenarios of high-volume user traffic that exceeds the capacity of a single machine. By understanding the Controller-Worker architecture and carefully configuring the network, Java, and JMeter environments, you can effectively scale your load tests.
While there might be challenges, particularly around setup and configuration consistency, tools like Docker can greatly simplify the process. With the right setup, JMeter distributed testing can significantly improve performance, efficiency, and scalability testing strategy.
Additionally, integrating with platforms like BrowserStack Automate can help verify real-user experiences across various browsers and real devices, post load testing.