JMeter – Distributed Testing

JMeter - Distributed Testing (Master- Slave)

JMeter is an open-source performance testing tool. The popularity of JMeter is more than any other freeware performance testing tool. This is a lucrative PT tool because it has all the basic features like ease of installation, scripting, execution, reporting and support to all the basic protocols. Another good feature of JMeter is that you can customize the features easily to enhance its existing functionalities. That is why many third-party plugins are available on the internet which fulfils the tester’s requirement.

Apart from scripting component enhancement, when licensing and its pricing comes into the picture where a client needs to pay a big amount to borrow the paid licenses or cloud infrastructure to continue the execution of performance test; JMeter provides a free solution. Of course, the client has to invest some bucks on the physical/virtual machines. However which is less than the cost of purchased licenses. These physical/virtual machines are also known as Load Generator.

What is Distributed Testing in JMeter?

Distributed Testing in JMeter helps to scale-up the capacity of JMeter to generate the desired number of thread (users) to perform the Load Test. The distributed testing follows the master-slave architecture where JMeter resides on all the machines and interact via Java RMI (Remote Machine Invocation). 

In the distributed architecture, all the machines (master and slaves) are in the same (local) network. Among them, one machine is treated as a master which controls the other slave machines during test execution. The slave machines follow the instruction initiated by the master machine and then hit AUT (application under test) i.e. send the request to the target server.

A typical architecture of distributed testing is:

JMeter - Distributed Testing (Master-Slave) Architecture
Figure 01: JMeter Distributed Testing Architecture

How to set-up a distributed testing environment for JMeter?

Following points will help to set-up a distributed environment for JMeter:

  • Check –  how many threads can be handled by 1 machine?
  • Estimate – the number of required slaves (of same hardware & software configuration) based on the thread count handled by 1 machine. For example, if one machine can handle 200 threads and the target load is 1000 threads (users) then 5 (=1000/20) slaves machine will be required.
  • Install – the JMeter of the same version on all the slaves including Master. It is recommended that copy the same JMeter set-up on all the machines and do the installation.
  • Make Sure: 
    • The firewall should be turned off on all the machines.
    • Anti-virus should be disabled (not for all the case, only recommended when anti-virus interrupt the RMI communication between master and slaves).
    • All the machines (slaves and master) should be in the same network.
    • The target application (server) should be accessible from all the machines.     

Once this is done then the distributed environment is ready for test execution.

What are the steps to follow before starting the test in a distributed environment?

Once the script is completed and runnable at the local machine then there are some configuration settings which need to be done in JMeter installed at Master and Slave machine which are as follow:

Master Machine JMeter Configuration: To communicate with the slave machines, master machine’s jmeter.properties file needs to be updated. To modify the jmeter.properties of master machine follow these steps:

  1. Open <JMETER_HOME>/bin/jmeter.properties in notepad or notepad++
  2. Search using “remote_hosts” keyword.
  3. Add IP Address or Host Name of all the slave machines (name should be separated by comma).
JMeter - Distributed Testing (Master-Slave) setting
Figure 02: jmeter.properties File

Slave Machine JMeter Configuration: There is no such configuration to the set-up file of slave machines. But if the script has any external CSV test data file, text file, custom log file etc. then these files need to be placed at the correct, exact and same location in all the slave machines. The absolute or relative path of the file along with file name must be same for all the slave machines. It is advisable to place the test data file in bin folder of JMeter, so that only name of file can be provided instead of full path. This will reduce the probability of failing the test due to ‘file not found’ issue when the file path is wrong.

Another pre-requisite is to start the jmeter-server service on all the slave machines. This service can be started by executing the below command

For Unix

./jmeter-server

For Windows

jmeter-server.bat (on Windows)

The jmeter-server file is available in <JMETER_HOME>/bin folder. Once you hit the command then the below message must appear.

Figure 03: At Slave machine

You may get some challenges (or error) while starting jmeter-server service. The solutions for those common issues are provided in the challenge section.

How to execute a test on a distributed testing environment in JMeter?

Before starting the test in a distributed environment, the number of threads calculation is required. Let’s say the target user load is 1000 and there are 5 slaves then ‘Number of Threads (users)’ field will have the input as 200 (=1000/5). This is because the master machine sends a copy of the JMeter script to each slave machine and according to the script input each slave generates the load and executes the test. Likewise, the accumulative generated load is equal to the target load. Master machine JMeter does not have the capability to divide the number of threads according to the available slaves. Hence a manual intervention is required for the number of threads allocation.

JMeter - Distributed Testing (Master-Slave) Thread Group
Figure 04: Thread Group setting

JMeter distributed test execution can be conducted in two ways (similar to normal test execution)

1. GUI Mode: 

In GUI mode, JMeter UI is launched at the master machine. If the test needs to be started using specific slaves then those slaves need to be chosen from the Run menu. Follow the flow:

JMeter Menu -> Run -> Remote Start -> Click the name of the host (s)

Figure 05: Starting of Slave Machine(s)

To start the test using all the defined hosts (slaves) in one go, click on

JMeter Menu -> Run -> Remote Start All

OR

Press ‘Ctrl+Shift+R’

Figure 06

2. Non-GUI Mode: 

To execute the test in non-GUI mode, first navigate to the /bin folder of JMeter and run the following command:

For Windows:

jmeter -n -t <script path> -l <log file path> -r

For Unix:

./jmeter.sh -n -t <script path> -l <log file path> -r

The test can also be executed by selecting specific slave machines.

For Windows:

jmeter -n -t <script path> -l <log file path> -R server1,server2,server3,

For Unix:

./jmeter.sh -n -t <script path> -l <log file path> -R server1,server2,server3,

Important Points:

  1. Divide the target user load with the number of slave machines and use that figure as ‘Number of Threads (users)’ input in Thread Group.
  2. When a unique test data scenario needs to execute then test data in the CSV data set config file placed at different slave; must be unique. The same copy of the CSV file will produce duplicate data.
  3. All the slaves (load generators) must be in the same network so that there is no discrepancy in the network latency which impacts the result.
  4. This port can be controlled by JMeter property called client.rmi.localport in jmeter.properties. If there are any firewalls or other network filters between JMeter client and server, you will need to make sure that they are set up to allow the connections through.  

Confirmation of successful test start:

At Master End:

Figure 07

At Slave End:

Figure 08

Challenges in distributed testing:


Leave a Reply

Your email address will not be published. Required fields are marked *