Taking the 3-endpoint web application discussed in the previous article and the JMeter script we created, we will learn how to run tests in several servers at the same time and to obtain a consolidated report.
It’s important to bear in mind that the tests are distributed among all servers. So, if we have 3 servers and we want 6000 concurrent threads, we will configure the tests to have only 2000 threads, because the servers will generate 2000 each.
Starting JMeter in Server Mode
A simple way to check that everything is working properly is to locally test JMeter in server mode. From the terminal, we start the server with this command: “jmeter -s -Jserver.rmi.ssl.disable=true”. I’m using the property “disable SSL certification for RMI” because in my local computer, SSL is not configured for RMI, and besides, I really don’t need it now.
Even though using JMeter in distributed mode is very straightforward, we must meet three basic requirements:
- Having the same JMeter version installed in every server
- Having the same Java version installed in every server as well
- Having a valid keystore to enable RMI on SSL, or directly disabling SSL, like we did previously
Running Tests in a Remote Server
Once the server is started, we can begin running tests and configuring the servers we want with the following command: “jmeter -n -t jmeter.jmx -Rlocalhost -Jserver.rmi.ssl.disable=true”. Note that I’m only setting one remote server in localhost. As output, we will have something like this:
If there were more servers available, we just need to specify them in the parameter -R, separated by commas.
But in this case, we are just making 3 requests to a remote server. The configurations we discussed in the previous article can also be applied in this case: we can set the number of threads, the ramp-up period and the loop count, which will be transmitted to all the servers where we run the tests. It’s important to consider that if our tests need to read files —a CSV file, for example—, this methodology for running tests doesn’t distribute those files among the servers.
As an example, we can execute “jmeter -n -t jmeter.jmx -Gthreads=1000 -Grampup=33 -Rlocalhost -Jserver.rmi.ssl.disable=true”, indicating that we want 1000 threads and a ramp-up period of 33 seconds. Note that in order to set these properties in the remote servers we no longer use the parameter -J, but -G instead. The output will look like this:
Running Distributed Tests with Taurus
Running tests in distributed mode with Taurus is as easy as we have seen. We just need to add a few parameters in the configuration file to tell Taurus that we want to execute tests in distributed mode.
In this case, I had to add a parameter to disable the SSL certification, but it’s optional. Just like I set that parameter, you can set any other you need in order to configure the execution. My file test.yml looked as follows:
We can see that the section “- distributed” was added and I set “localhost”, but we can add as many servers as we need and list their IP addresses preceded by a dash (“-”).
We are now ready to run the tests in distributed mode. Doing it in one server or in 10 is just as easy. The interesting thing is that it’s possible to use our local computer and domestic connection to monitor infrastructure, just like Amazon offers to do for our nodes. In this way, we can generate a load that otherwise would be almost impossible.
Monitoring the Status of the Nodes
When we do stress tests, we risk discovering that the tests themselves create a bottleneck and not the software we are testing. And it’s likely that we won’t be able to push the software to the limit because our testing and infrastructure aren’t enough to stress the application.
Taurus offers the possibility by default to monitor the server where the tests are running, which is useful when we are working with more than one node. However, I don’t find it as convenient because there are other tools for doing that. When tests are running in several servers, it’s important to be able to monitor and visualize the status in one place. It’s advisable to install a Java application in each one of the servers: PerfMon Server Agent, showing which endpoint we can ask for stats.
We just have to download it and execute it in each one of the nodes with the script “startAgent.sh” included in the .zip file. Then, we have to indicate in the configuration file that we want to obtain those metrics, so in the file “test.yml” we add a few lines of code and get something like this:
- module: monitoring
- address: localhost:4444
We must add as many server-agent as servers we have. In my case, I only have one set in localhost, so in the address I put “localhost: 4444”. If we are running in a different server, we should specify the IP address and the port. We could even change “localhost” for “127.0.0.1:4444”.
It’s important to define the metrics that will help us understand better. For certain tests, you may need to measure the status of the network connections. With this configuration, the output will look like this:
The size of the screen can be a limiting factor for adequately visualizing the data. If you added new sections in the configuration and don’t see them, you will likely have to enlarge the screen where you are visualizing Taurus output.
For reporting, we can use the same tools we discussed in the previous article, Blazemeter being one of the best. Just by invoking Taurus with the parameter “-report”, we can see it in the interface. Even though we are monitoring the servers, the tab “Engine health” won’t show anything because it’s a functionality that works with their specific infrastructure.
Nevertheless, Blazemeter’s reporting feature is really good and includes all the functionalities we like, such as timeline report, which allows to create charts like the following:
That’s all for now. Thank you for reading this and have a happy testing!