JMeter-Distributed Testing
An open-source performance testing tool is JMeter. JMeter is more famous than other free performance testing tools. With all the essential features including easy installation, scripting, execution, reporting, and support for all the essential protocols, this PT tool is very cost-effective. The ease with which JMeter’s capabilities can be modified to enhance existing functionality is another positive aspect. Because of this, many third-party plugins that meet the needs of testers are available online.
What is JMeter distributed testing?
JMeter’s distributed testing capability allows you to scale capacity and produce the required number of threads (users) for load testing. When running distributed tests, JMeter is installed on each machine and communicates with other machines using Java RMI (Remote Machine Invocation).
All machines (master and slave) in the distributed architecture are connected to the same local network. One of them is assigned the role of master, controlling the other machines while the test is running. Slave machines execute the instructions of the master machine before sending the request to the destination server by pressing AUT or the application under test.
How can I set up the JMeter distributed test environment?
Find out how many threads a computer can handle.
Calculate the required number of slaves (with the same hardware and software configuration) based on the number of threads a single machine can handle. For example, if the target load is 1000 threads (users) and one machine can handle 200 threads, five (= 1000/20) slave machines are needed.
Install the same version of JMeter on the master and all the slaves. It is recommended to install JMeter with exactly the same configuration on all workstations.
Make sure:
All computers should have their firewalls turned off.
Antivirus must be disabled (not always; recommended only when antivirus interferes with RMI communication between slave and master).
Both the slave and master machines must have an identical network.
All machines must have access to the target application (server).
How can I run a test with JMeter in a distributed test environment?
Before starting the test in a distributed environment, the calculation of the number of threads is required. Let’s say the target user load is 1000 and there are 5 slaves, then the ‘Number of threads (users)’ field will have the entry as 200 (= 1000/5). This is because the master machine sends a copy of the JMeter script to each slave machine, and based on the script input, each slave generates the payload and performs the test. Similarly, the cumulatively generated charge is equal to the target charge. The JMeter master machine does not have the ability to distribute the number of threads based on the available slaves. Therefore, manual intervention is required for the allocation of the number of threads.
There are two approaches to running distributed tests using JMeter (much like a traditional test run).
1. GUI Mode:
JMeter UI is opened at the master computer in GUI mode. If a specific slave is required to start the test, that slave must be selected from the Run menu. Adhere to the flow:
Click on to launch the test utilizing all of the defined hosts (slaves) at once.
Run > Remote Start All from the JMeter menu
2. Non-GUI Mode: Go to JMeter’s /bin folder and enter the following command to run the test in non-GUI mode.
Using Windows:
Jmeter –notation –script path -l path to log file> -r
Using Unix:
./jmeter.sh -l “log file path” -n “script path” -r
Additionally, the test can be run by picking particular slave machines.
Using Windows:
Jmeter –notation –script path -l path to log file> -R servers 1, 2, and 3.
Using Unix:
./jmeter.sh -l “log file path” -n “script path” -R servers 1, 2, and 3.
Important Information
Use the result as input for the “Number of threads (users)” in the thread pool by dividing the target user load by the number of slave computers.
The test data in the CSV data set configuration file placed on individual slaves must be different when running a single test data scenario. CSV file produces duplicate data when used.
To ensure that there is no variation in network latency affecting the result, all slaves (load generators) must be connected to the same network.
The JMeter property client. rmi. local port in jmeter.properties can manage this port. You must ensure that any firewalls or other network filters are configured between the JMeter client and the server.
Confirmation of successful test start:
At the master end:
At slave end:
