Apache JMeter’s DISTRIBUTED TESTING

Swetha PN
6 min readJan 30, 2023

--

A single JMeter client/system running on a 2–3 GHz CPU can handle up to 1000 threads or virtual users, depending on the type and duration of the test. However, in real-time due to constraints on the network, including memory and CPU utilization, a single test machine can sustain a load anywhere between 500 to 700 users and that is with headless testing (non-GUI)

So, how do we cater to testing when the requirement is to inject more than 500 users?

The solution is to distribute the load generation task to multiple slave machines.

Distribution Testing Architecture

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)

Note: If the slave and master are on the same machines, it is a 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

  • Ensure Java and JMeter version matches between the 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 Test Scripts and CSV files used in the test scripts explicitly on Slave machines

Steps to Achieve the Distributed Testing on JMeter

To implement distributed testing, you should follow the four steps below:

1. RMI Key generation (optional)

2. Free Ports and open Firewalls to enable Connectivity among machines

3. Start Slave machines

4. Start Master Machine

RMI Key generation

This is to add the security layer. As this is optional, you can skip this step as well, although it is recommended.

To skip this step: Make sure the below RMI attribute is set to disabled in the jmeter.properties file

JMeter Properties file in bin folder

Otherwise, follow the below steps to generate the file:

  • First, delete the old rmi_keystore.jks, if any, from the JMeter bin folder
  • Open the command prompt(cmd) in admin mode and then run the following commands
Screenshot of Command Prompt

1. Cd to Java on your machine

cd C:\Program Files\Java\jre1.8.0_201\bin

2. 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

3. You can also set a blank password by simply clicking the Enter key

Move the JKS file created to the JMeter bin folder.

Once this process is finished, the generated certificate should be 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.

Note: Recommended to not disable SSL, hence better to generate the RMI key store file

Enable Ports:

By default, RMI uses dynamic ports for the JMeter server engine.

JMeter properties file in the bin folder

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. Launch the JMeter-server (.bat on Windows or. sh on Unix) file from the JMeter/bin folder to start a slave. Repeat this step for every slave machine.

If the server starts without errors, this is what you should see:

Jmeter-Server.bat Console

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 numbers) of all the slaves that you have set up.

Add the IP address of Slave machines separated by a comma

Once all the steps are completed, it is time to restart JMeter.

Start the Test

On the master machine, run JMeter (.jar or .bat on Windows, and. sh on Unix). Open any script with the 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).

Master: Click on Remote Start or Remote Start All

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.

Master: Top right corner Green indicating the test has begun
Slave Machine: Starting and Finished the test indicating Test Status

Results

The Summary Report 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)

TIPS

If you are unable to start the test execution on remote machines (slaves running JMeter-server) due to Connection time-out errors

Common connectivity error due to Firewall
  • Try using ping or telnet commands to ensure Master can ping to 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.

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 the master and slaves is not possible. At times like these, as an interim solution, we can use parallel testing.

What is parallel testing?

Parallel testing involves running the test scripts in different machines at the same time and accounting for the concurrent load on the AUT. This is in contrast to the distributed testing approach.

Under distributed computing, all machines are synchronized and in constant communication. The master machine tells the slave machines when to start and stop the test, and the slave machines send test results to the master machine in near real-time.

Merge Results is a tool to merge multiple files of results

With parallel testing, install JMeter on multiple machines and trigger the tests against the AUT at the same time. Once the tests are complete, with the help of the merge results plugin, you can merge multiple results files together into a single jtl file, thereby generating a single Load test report.

Jar to download: jmeter-plugins-mergeresults-2.1.jar.

Source: https://jmeter-plugins.org/wiki/MergeResults/

Download the above plugin from Plugin Manager and place it in the ext. folder of JMeter.

JMeter ext folder to save the jar file

Restart JMeter. Follow the below steps in order to merge two JTL files and generate a single JTL

Add the Merge Results element in JMeter Test Plan

Once the Merge Results tab opens, browse the JTL files and insert the path to the Output file before clicking the Merge button. If the output file already exists, it will be overwritten.

The same can be accomplished from Command line as follows:

Happy Testing!

--

--

Swetha PN
Swetha PN

No responses yet