Distributed Performance testing

As a modern enterprise, your customers expect 100% availability of your critical web and mobile applications. Unforeseen events such as COVID-19, have necessitated many customer engagements to become virtual. This has made web and mobile applications even more critical.

Distributed performance Testing helps you automate the performance testing of your software applications at scale. This way you can identify bottlenecks before releasing your application. The solution supports scheduled and concurrent tests, and handles increased numbers of simultaneous users who can generate many requests per second. It also offers real-time reporting. You can simulate thousands of users connecting to your application, so you can better understand your application performance profile.

Companies that must test their website performance can benefit significantly from the solution. They can use default load tests such as simple GET requests, or use JMeter scripts to create custom tests.

Now, with distributed load testing, you’ll take all of these steps for load testing and put this directly onto a cloud instance, from where load can be generated on your APIs. Distributed testing gives you with the ability to incorporate your advanced scenarios on the cloud and then generate load from there. It also provides you a lot of visibility into your load generators, which could be hosted on any cloud platform, AWS, Azure, etc.

Say you have a system for load testing within your own network. You use your machine to generate traffic and you hit it with 500 users and get a certain response time. What this ignores is the global latency. With distributed architecture we can place nodes which are globally distributed across regions.

Distributed Testing in JMeter

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.

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.

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:

1. The firewall should be turned off on all the machines.

2. Anti-virus should be disabled (not for all the case, only recommended when anti-virus interrupt the RMI communication between master and slaves).

3. All the machines (slaves and master) should be in the same network.

4. 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).

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

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)

Get Digital Optisol’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

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

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?

1. Before starting the test in a distributed environment, the number of threads calculation is required.
2. Set target user load is 1000 and there are 5 slaves then ‘Number of Threads (users)’ field will have the input as 200 (=1000/5).
3. 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.
4. 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.
5. Manual intervention is required for the number of threads allocation.

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)

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

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,

Critical 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:

At Slave End: