How to Perform Distributed Testing in JMeter

Should you do distributed testing in JMeter? And how do you do it? Find out in this blog!

Why Do Distributed Testing in JMeter?

If you have an e-commerce site (or any site for that matter), it’s not uncommon that you would expect a higher level of traffic on certain days, like Black Friday for example. At moments like these, we need to take our load tests to the next level and simulate larger numbers of concurrent users. If we are running our load tests locally with Apache JMeter™, there are certain limitations to the number of users you can run, even if your computer has enough CPU and memory. That's why it's important to know how to perform distributed testing in JMeter.

📕 Related Resource: JMeter Tutorial: Getting Started With the Basics

How to Do Distributed Testing in JMeter

How can we create an scenario with more than 800 concurrent users using JMeter? One of the answers is running JMeter in distributed mode. For those of you who have never heard about it, here is a brief explanation.

When we talk about distributing JMeter, we refer to a Master-Slave architecture where JMeter uses Java RMI [Remote Method Invocation] to interact with objects in a distributed network. You can see this in the image below.

Distributed testing enables having a local JMeter (master) that handles the test execution, together with multiple remote JMeter instances (slaves) that will send the request to our target server.

But before being able to run JMeter in a distributed way, there are a couple of simple steps you must perform.

First, we need to have multiple computers.

Then we need to get the JMeter Server running on each slave system that we have. For that purpose we have to execute the jmeter-server.bat (jmeter-server for unix users) that is located in the jmeter/bin. Once we run it we should see something like this:

Then, through the same path, but in the master system, locate the jmeter.properties file. Edit this file and add the IPs of all the slave systems that should be involved in the property remote_hosts. Make sure the master and the slave systems are located in the same subnet.

It’s very important to remember that all the values must be separated by commas (in this example we are using just one slave system, just to keep it simple).

Once all of these steps are accomplished, we can start JMeter and execute the tests we need. In this case we are going to execute JMeter using GUI Mode, so we can have a better idea of how it works. However, non-GUI mode is strongly recommended for testing purposes.

If you want to run JMeter in non-GUI, you can do that in two ways:

• jmeter -n -t script.jmx -r
• jmeter -n -t script.jmx -R server1,server2,...

You may also find some of the flags below useful for running JMeter from the command-line:

• n to start Jmeter in a non-gui mode
• t to define the test file
• r to start the remote server as defined in the JMeter properties file
• R to define the list of servers and start them
• -Gproperty=value, define a property in all the servers (e.g -Gport=123), for further information refer to this post.
• -Z, Exit remote servers at the end of the test.

Back to GUI mode, the number of users, ramp up and iterations should be configured in the master system´s Thread Group as usual. When running the test, these conditions will be replicated on each slave system.

After starting JMeter and loading our test, we have two options. One, configured through the master system, is through Run->Remote Start and then select the slave system where we want to execute. The second, also configured through the master system, is Run->Remote Start All to start the test on all available slave systems.

(As we set just one slave system, there no difference between the two options in this example).

Here we have a simple scenario where we can search and view an article on an e-commerce site:

As you can see, we have added a View Results Tree listener so we can check whether the test was executed correctly or not. When we run a test remotely, we are going to be able to locally see the test result on the View Results Tree listener as I already mentioned, but in the slave systems we can only observe the start time and the end time of the test.

Locally:

Remotely:

Behind the scenes, each slave system is executing the load tests with the conditions that we set in the master system. This way, we are achieving a higher number of concurrent users, and hence a higher load to our target server.

Therefore, if we want to really distribute the load, we have to do it manually. E.g: if we want to reach 10,000 concurrent users and we have 10 slave systems, our test plan must have 1000 users, so we end up having 10,000 total.

Another interesting thing we can do is to add logic to our test by adding an If Controller. The If Controller allows us to choose a particular flow we want to execute, depending on the system that is executing the test. So, different slave systems would be running different parts of the test.

For example if we add a parameter when running the jmeter-server on the slave systems (./jmeter-server -Jparam=1) we can place a condition like ${__groovy(${__P(param)}==1)} within the If Controller, so we can execute particular requests depending on the slave system. Another possibility is to invoke __machineIP()  or __machineName() within the if controller, instead of adding a parameter to JMeter’s instances.  If you want to know more about If Controllers, please check out this blog.

That’s it! We have successfully executed a test over a JMeter distributed system.

Challenges in JMeter Distributed Testing

This may not look very complex because we chose to use only one slave system. But if you need to simulate 25,000 concurrent users, the cost of maintaining all of these systems is huge. There may be a possible workaround for the maintenance issues and that is to mount all the architecture that we have seen over Docker containers (you can see an example here on Vinsguru).

However, this still won’t be good enough if our aim is to run load tests periodically. We have mounted all the distributed architecture in one computer, so we are consuming a considerable amount of resources. The concept of distributing JMeter over Docker makes more sense if we have the possibility to escalate the number of containers on demand, like in a cloud computing service.

Another difficulty when running JMeter in distributed mode, is how to handle CSV files when you have parametrized data in your tests. This is because we need to have separated files, and if we have to update them we have to go to each slave system and make the modifications.

To solve all of these limitations and inconveniences we can use BlazeMeter, which provides us with an easy way to handle our load tests. All we need to do is to upload our JMX file to BlazeMeter. We can also upload a consolidated CSV file with all the necessary data and BlazeMeter will take care of splitting it, depending on the amount of engines we have set.

On BlazeMeter we can set the amount of users or the combination of engines (slave systems) and threads that we want to apply to our tests. We can also configure additional values like multi locations.

Test results:

That’s it! Now you have seen a few solutions for running load tests on a large scale, my recommendation for you is to create your own experience and make a decision about which option provides you with greater benefits.

Learn more about how to use JMeter from our free BlazeMeter University.

START TESTING NOW

Related Resources:

• JMeter Distributed Testing with Docker