What are the limitations of JMeter

Set up a JMeter cluster for web server load tests

This tutorial shows you how to set up a JMeter cluster for load testing. Like anyone who is new to it, the Apache JMeter application is open source software, a 100% pure Java application that was developed for testing functional behavior and measuring performance. It was originally developed for testing web applications, but has since expanded to other testing functions. It can be used to simulate a heavy load on a server, server group, network, or object to test strength or analyze overall performance under different types of loads.

But as every approach to business grows, engineers and testers need to conduct more tests to ensure that each expansion module can serve larger customers without affecting day-to-day production operations. To ensure this, JMeter has introduced its own services by allowing the performance test to be performed under larger environments as a clustering process.

If your JMeter client computer is unable to simulate enough users to load your server or is limited at the network level, you can control multiple remote JMeter engines from a single JMeter client. Running JMeter remotely allows you to replicate a test on many low-end computers and simulate a larger load on the server. One instance of the JMeter client can control any number of remote JMeter instances and collect all data from them.

Distributed tests are a type of test that uses multiple systems to conduct stress tests. Distributed testing is used to test websites and server applications when they are working with multiple clients at the same time.

1. How does it work?

When we do our load tests locally with a single JMeter application, there are certain limitations on the number of users you can run, even if your computer has enough CPU and memory. So how can we create a scenario with 1000+ concurrent users using JMeter? Because of this scenario, the idea of ​​JMeter in distributed mode comes into the picture.

When we talk about JMeter distribution, we are referring to a master-slave architecture where JMeter uses Java RMI [Remote Method Invocation] to interact with objects on a distributed network. The following images are intended to summarize the workflow:

By using JMeter in the cluster design, you can ensure that your tests have the ability to have a local JMeter (master) that does the test execution along with multiple remote JMeter instances (slaves) sending the request to your target server , handles.

The connection to the JMeter cluster / JMeter service can be established via:

  1. JMeter desktop application
  2. SSH / Terminal
  3. VNC
  4. API service endpoint (WIP)

2. Installation phase

For the installation phase, we will first list the inventory of the individual servers. Below are the details:

System inventory
IPHostnameOSfunctionstatus
172.20.0.111jmeter01CentOS 7 x64 bitJMeter server 01 (master / slave)ready
172.20.0.112jmeter02CentOS 7 x64 bitJMeter server 02 (slave)ready
172.20.0.113jmeter03CentOS 7 x64 bitJMeter server 03 (slave)ready
172.20.0.114jmeter04CentOS 7 x64 bitJMeter server 04 (slave)ready

Now let's get our hands dirty, we're going to start setting up the server with prerequisites, assuming that each server is under a minimal server configuration. Below are the steps:

[[email protected] /] # yum install -y wget initscripts net-tools

The above procedure is optional to ensure our installation and verification goes smoothly. Once the installation is complete, you will see the screenshot as below

Next we need to install Java packages as this is mandatory for setting up JMeter as a service. Below are the steps:

[[email protected] /] # wget --no-cookies --no-check-certificate --header "Cookie: gpw_e24 = http% 3A% 2F% 2Fwww.oracle.com% 2F; oraclelicense = accept-securebackup-cookie "" http://download.oracle.com/otn-pub/java/jdk/8u131-b11/d54c1d3a095b4ff2b6607d096fa80163/jdk-8u131-linux-x64.rpm "[[email protected] /] # yum localinstall -y jdk- 8u131-linux-x64.rpm

The process will go as described below:

Next we will install the JMeter packages. In this tutorial I will be using the current stable version for JMeter installation. The steps are as below:

[[email protected] /] # wget https://www-eu.apache.org/dist//jmeter/binaries/apache-jmeter-5.1.1.tgz [[email protected] /] # tar -zxf apache- jmeter-5.1.1.tgz [[email protected] /] # ln -s /apache-jmeter-5.1.1 $ HOME / jmeter [[email protected] /] # echo "export JMETER_HOME = $ HOME / jmeter" >> /root/.bashrc [[email protected] /] # echo "export PATH = $ PATH: $ JMETER_HOME / bin" >> /root/.bashrc [[email protected] /] # source /root/.bashrc [[email protected] /] # curl -L https://jmeter-plugins.org/get/> $ HOME / jmeter / lib / ext / plugins-manager.jar [[email protected] /] # curl -L https: // repo1.maven.org/maven2/kg/apc/cmdrunner/2.2/cmdrunner-2.2.jar> $ HOME / jmeter / lib / cmdrunner-2.2.jar

When everything is done, you will see the progress as shown below

Next, we're going to use a plugin manager to install several Java packages that are needed for our JMeter to run smoothly. Below are the steps:

[[email protected] /] # java -cp $ HOME / jmeter / lib / ext / plugins-manager.jar org.jmeterplugins.repository.PluginManagerCMDInstaller [[email protected] /] # /root/jmeter/bin/PluginsManagerCMD.sh install jpgc-autostop, jpgc-casutg, jpgc-csl, jpgc-dummy, jpgc-ffw, jpgc-filterresults, jpgc-functions, jpgc-json, jpgc-mergeresults, jpgc-prmctl, jpgc-sense, jpgc-tst, jpgc -wsc

If the progress goes smoothly, you will get as below screenshot

Now that everything is done on the installation part, you have to create the keystore as a slave before starting JMeter. To do this we can use a script bundled with Apache JMeter packages called create-rmi-keystore.sh. The following are the steps: -

[[email protected] ~] # $ HOME / jmeter / bin / create-rmi-keystore.sh

You can see the screenshot below

Now we've done pretty much everything for the JMeter installation, and we can proceed with the configuration in the JMeter service for the distribution process. You can proceed with setting up the rest of the JMeter server as you did with the same installation that you performed for this server.

3. Configuration phase

As for the configuration as a distributed JMeter, we only have to edit the jmeter.properties within the JMeter / bin folder as described below

[[email protected] ~] # vim /root/jmeter/bin/jmeter.properties remote_hosts = 172.20.0.111, 172.20.0.112, 172.20.0.113, 172.20.0.114

Notice that I have included all of our JMeter servers in the JMeter configuration file. By default, the configuration is as remote_hosts = 127.0.0.1 specified. For this configuration you only need to configure it under JMeter servers assigned as masters.

4. Test phase

With everything done, let's test and compare the results for individual JMeter load tests and JMeter distributed load.

Before starting the test, let's make the assumption about the expectation of the end result. For this test we will try to run a database query that was called from one location. We are going to use the URL to access the site and include it in the JMX file to be run by the JMeter service. This tutorial does not cover the step of creating a JMX file.

Just for the sake of clarity, below is the simple query we'll be using to run from the database via a web url:

[[email protected] ~] # mysql -u shahril -p -h 10.124.12.13 Enter password: Welcome to the MariaDB monitor. Commands end with; or \ g. Your MySQL connection id is 546695 Server version: 5.7.20-log MySQL Community Server (GPL)

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\ h' for help. Type '\ c' to clear the current input statement.

MySQL [(none)]> SELECT 1 FROM cassie_devdb.saml_users WHERE (username = ‚[email protected]‘) LIMIT 1;
+—+
| 1 |
+—+
| 1 |
+—+
1 row in set (0.00 sec)

For your information, you can use any query for this tutorial. Since this query has not been tuned, it is expected to increase CPU resources if it is run by multiple sessions that we will schedule with the help of the JMeter service

Now that everything is prepared and understood, let's start all of the JMeter servers. The following is the command:

[[email protected] ~] # $ HOME / jmeter / bin / jmeter-server & [1] 6149

To continue with the test, we will run the JMX file that will trigger the above query in a single JMeter server, as described below:

[[email protected] /] # / root / jmeter / bin / jmeter -n -t /opt/jmeter/shahril_loadtest/testing.jmx

Notice that `testing.jmx` was the JMX file containing the execution thread. Once the above file has run, you will see the result as in the following screenshot

Next we run the same JMX file towards JMeter in a distributed environment. Below are the steps:

[[email protected] /] # / root / jmeter / bin / jmeter -n -t /opt/jmeter/shahril_loadtest/testing.jmx -R 172.20.0.111,172.20.0.112,172.20.0.113,172.20.0.114

Note that the command is pretty much the same when run in a single phase, you just need to add a flag of -R and add the other JMeter server to include in execution. You can see the details of the listed flag that the JMeter command returns, as shown below:

[[email protected] /] # / root / jmeter / bin / jmeter --help _ ____ _ ____ _ _ _____ _ __ __ _____ _____ _____ ____ / \ | _ \ / \ / ___ | | | | ____ | | | \ / | ____ | _ _ | ____ | _ \ / _ \ | | _) / _ \ | | | | _ | | _ | _ | | | \ / | | _ | | | | _ | | | _) | / ___ \ | __ / ___ \ | ___ | _ | | ___ | | _ | | | | | | ___ | | | | ___ | _ / _ / \ _ \ _ | / _ / \ _ \ ____ | _ | | _ | _____ | \ ___ / | _ | | _ | _____ | | _ | | _____ | _ | \ _ \ 5.1.1 r1855137 Copyright (c) 1999-2019 The Apache Software Foundation To list all command line options, open a command prompt and type: jmeter.bat (Windows) /jmeter.sh (Linux) -? -------------------------------------------------- To run Apache JMeter in GUI mode, open a command prompt and type: jmeter.bat (Windows) /jmeter.sh (Linux) [-p property-file] --------------- ----------------------------------- To run Apache JMeter in NON_GUI mode: Open a command prompt (or Unix shell) and type: jmeter.bat (Windows) /jmeter.sh (Linux) -n -t test-file [-p property-file] [-l results-file] [-j log-file] ---- ---------------------------------------------- To run Apache JMeter in NON_GUI mode and generate a report at end: Open a command prompt (or Unix shell) and type: jmeter.bat (Windows) /jmeter.sh (Linux) -n -t test-file [-p property-file] [ -l results-file] [-j log-file] -e -o [Path to output folder] --------------------------- ----------------------- To generate a report from existing CSV file: Open a command prompt (or Unix shell) and type: jmeter.bat (Windows) /jmeter.sh(Linux) -g [csv results file] -o [path to output folder (empty or not existing)] -------------------- ------------------------------ To tell Apache JMeter to use a proxy server: Open a command prompt and type: jmeter.bat (Windows) /jmeter.sh (Linux) -H [your.proxy.server] -P [your proxy server port] ----------------------- ---------------------------- To run Apache JMeter in server mode: Open a command prompt and type: jmeter-server.bat (Windows ) / jmeter-server (Linux) ------------------------------------------ ---------

Once the JMX file has run under a distributed environment, you will see the result as shown in the following figure

Great, now we have successfully run our test in both environmental phases. To see the comparison differences, I set up a monitoring dashboard with Grafana. Since this is just to show the differences in results, we won't go into how to set up Grafana as a monitoring dashboard

Based on the CPU usage taken by the target server hosting our website, below are the results under individual JMeter threads:

And below the picture are the results under the distributed JMeter thread:

From the comparison above, we can clearly see that we can manage to introduce more threads into the target server to see the limitation of an application that can accept them.