Written By: Swetha Pujari
A single JMeter client/system running on a 2–3 GHz CPU can handle up to 1000 threads or virtual users, depending on the test’s type and duration. However, in real-time, due to constraints on the CPU, memory, and network(socket related), a single test machine may sustain load anywhere between 500 to 700 users despite using headless (non-GUI) testing. Besides, maximum thread handling capacity also depends on various other factors, which means this number can be even less than 500. So, how do we cater to tests when the requirement is to inject thousands of users?
The solution is to distribute the load generation task to multiple slave machines.
Distribution testing is this format of having a Master machine control the test and collate the results, while the slave machines work solely to generate the load against the application-under-test (AUT). Refer to the above snapshot (Figure 01)
Note: If the Slave and Master are the same machine, it is Non-Distributed testing approach.
Distributed Testing Components
- Master: The system running JMeter GUI/non-GUI, controls each slave and receives test execution information (collected metrics, threads/virtual Users activities, errors, etc.) from them.
- Slave: The system running JMeter-Server(jmeter-server.bat) receives a command from the master and sends a request to the server which is the application under test.
- Target: The Application or server under test.
Pre-requisites for Distributed Test
- Ensure Java and JMeter version matches between Master and Slave machine
- All machines are to be under the same subnet (IP address)
- Turn off the Firewalls preferably
- Any plugins/ jars/ reporting saving jtl file configurations are to be similar in all machines. It is best to have the same JMeter tool folder installed on all machines involved in the testing to avoid discrepancies
- Save the ‘jmx File (Test Scripts)’ and ‘CSV files used in the jmx scripts’ explicitly on Slave machines
Steps to Achieve the Distributed Testing on JMeter
To implement Distributed Testing, you should follow the below four steps:
- RMI Key Generation (optional)
- Free Ports and open Firewalls to enable Connectivity amongst machines
- Start Slave machines
- Start Master Machine
RMI Key Generation
This step ensures that there is a secured connection between the Master and the Slave machines. Although this is an optional step, it is highly recommended.
To skip this step: Make sure the below rmi attribute is set to disable in jmeter.properties file. This is by default.
Otherwise, follow the below steps to generate the file:
- To set up the SSL Key – certification pair, execute the create-rmi-keystore file JMeter\bin (which is a .bat file if your OS is Windows, and a .sh if you are using UNIX).
- Answer to the questions the program asks and you can type anything as long as it is accepted by the key/cert pair generation script.
- Set a blank password to avoid additional configuration on user.properties file
- This will create the rmi_keystore.jks file in the JMeter/bin folder
You will need to copy and paste it to the same folder in all the slave machines that will be involved in the Distributed Testing.
By default, RMI uses dynamic ports for the JMeter server engine.
You can edit it to an open and available port on your machine. Using the same one also works.
Control Panel -> Security and Maintenance -> Network Firewall -> Advanced settings -> Incoming and Outgoing bound rules
(Add new -> Port -> TCP Protocol -> All Ports -> Enable)
Initiating Slave Machines
We are almost there, but before executing the test script, we have to initialize the slaves and master. In order to start a slave, launch the jmeter-server (.bat on Windows and .sh on Unix) file from JMeter/bin folder. Repeat this step for every slave machine.
If the server starts without errors that is what you should see:
Master Set UP
Configuring the master node is simpler than doing that for the slave nodes. You just need to open the jmeter.properties file, find the remote_hosts property, uncomment it and type the IP addresses (without port number) of all the slaves that you have set up.
Add the IP address of Slave machines separated by comma.
Once you performed all the above mentioned steps then restart JMeter.
Start the Test
Launch JMeter (.jar or .bat on Windows and .sh on Unix) on Master machine. Open any script with .jmx extension and go to Menu and select Run >> click Remote Start All (or Remote Start to select individual slave machines to run your test script).
You will be able to see whether the test execution has begun by looking at the master’s GUI or on your slave jmeter-server script console.
The Summary Report will be available on the master machine. All you need to do after the test is finished is to grab the test results from the Summary Report and generate the report via JMeter (or do your analysis job)
If you are unable to start the test on slaves running jmeter-server due to Connection time-out errors
- Try using ping or telnet commands to ensure Master can ping to the IP address of Slave machines
- Check if the slaves’ firewalls are configured to allow incoming connections on the TCP ports that are configured in the JMeter properties: server.rmi.localport and server.rmi.port property.
RMI key-cert pair generation:
In case, you cannot find the create-rmi-keystore.bat file in the JMeter bin folder
- Open command prompt(cmd) in admin mode and then run the following commands
- Navigate to Java in your machine
cd C:\Program Files\Java\jre1.8.0_201\bin
- Run the below command to generate the rmi key file
C:\Program Files\Java\jre1.8.0_201\bin>keytool -genkey -keyalg RSA -alias rmi -keystore rmi_keystore.jks -storepass changeit -validity 7 -keysize 2048
- Navigate to Java in your machine
Move the jks file created from the Java folder to the JMeter bin folder.
Once this process is finished, the generated certificate should be in JMeter\bin folder.
Alternate Approach in case Distributed Testing with slaves does not work
Despite the efforts, sometimes due to the company’s network/firewall policy, sometimes setting up the connectivity between master and slaves is not possible. At times like these, as an interim solution, we can use parallel testing. >> Read More