Performance Testing Using Apache JMeter

By Alex Mungai Muchiri, Alibaba Cloud Tech Share Author. Tech Share is Alibaba Cloud’s incentive program to encourage the sharing of technical knowledge and best practices within the cloud community.

So, you have subscribed to an Alibaba Cloud service and deployed your system, but have you tested it yet? Testing software performance is one of the most important aspects of development. Performance testing is used by software developers and ICT experts to ascertain the behavior of the system under various workload conditions. It forms a key component of quality assurance. Software performance constitutes one of the major non-function testings of software systems. There are two types of performance tests that are classified as:

  1. Load testing
  2. Stress testing

Load testing involves subjecting the software to an anticipated load and observing its performance. The Application Under Test in stress testing is subjected to workload levels beyond what is expected to handle. The test determines the breaking point of the software.

Apache JMeter is a performance testing tool that simulates high workload. Developed by Apache Foundation, the tool is one of the most popular testing tools in existence. Its uses range from web application testing, REST APIs, SOAP APIs, and mobile applications. It tests both functional performance and behavior. Developers use the tool to simulate heavy loads on virtual servers, networks to check strength, tests the ability to handle heavy loads and determine system performance for a variety of loads.

Getting Started

Avoid running the tests on a live production server because it may compromise system performance and negatively affect services. This tutorial could be applied to any web applications that have been deployed.

One of the most useful properties of JMeter is the ability to skew tests depending on a variety of metrics. You could vary the computing resources available to JMeter as well as network bandwidth between the tool and the test server. However, you can increase the load pushed to the server under test by running non-graphical JMeter tests or having it distributed across JMeter servers.

JMeter Installation

  1. Oracle Java or OpenJDK (version 6 and above)
  2. Apache JMeter

Installing Java is simple for all operating systems, but you may have to help JMeter find Java and keytool binaries by adding a Java bin directory in your PATH environment. The PATH where JMeter was installed will be referred to as $JMETER_HOME. For Linux-based operating systems, the binary can be found at $JMETER_HOME/bin/jmeter. In Windows operating systems, it is located at $JMETER_HOME/bin/jmeter.bat.

The JMeter tool that has been installed on your personal computer will be used to plan for your tests, running load tests, and analyzing load tests. It has a guided interface for you to create manual plans, select plan templates, or record browser sessions. You can also use the interface for debugging and accessing results. After preparing the test plans, the command line is used to run tests in a non-GUI mode that can either yield a CSV or XML file. JMeter can then generate reports from the data in HTML formats. Since the tool is based on Java, you should have no problem running it in any platform where Java is installed.

If you plan on JDBC testing, install a JDBC driver to your database cross path or alternatively, include in the jmeterlib folder a jar file.

The simple installation procedure for Java is as follows:

On Windows, download and run the executable file on your computer.

For CentOS 7.x, download the updated rpm and run the command below:

yum localinstall jdk-8u152-linux-x64.rpm

In Ubuntu 16 system, run the command below:

sudo apt-get install oracle-java8-installer

The file directory for the installed Apache JMeter is as shown in the image below. The image also includes tests, results, and report directories

In the lib directory above, you can add any jar files that you need for your tests such as JDBC database drivers. You are recommended to store test scripts in the tests directory. The reports directory stores generated HTML Dashboard Reports while the results directory stores results.

Creating Your Test Plan

  1. Thread Groups
  2. Logic controllers
  3. Sample generating controllers
  4. Listeners
  5. Timers
  6. Assertions
  7. Configuration elements

The interface has a list of elements that can be added to the test plan. Furthermore, when you choose an element from the tree, changes take effect immediately, just remember to save to a file prior to running the test. The file menu has an option to “Save” or “Save Test Plan as”. Also, check the “Save Workbench” so that it is saved alongside the test plan.

On the Run menu, there is a Start option to run any test plans. The Stop command initiates the stoppage of the threads at the next possible moment. A Shutdown prompt will stop the run after all the runs have completed and do not interrupt active work.

Test Plan Elements

Configuration Elements

  1. HTTP requests default used for HTTP requests such as server name, IP, port number etc.
  2. HTTP cookie manager
  3. Variables defined by the user to store data such as usernames and passwords

Thread Groups

  1. Define the threads for tests
  2. Define the ramp-up time
  3. Define the number of test runs

All threads are independent of each other during execution, but collectively, they contribute to the successful execution of the test. You can also have concurrent threads connecting to your server. JMeter uses the ramp-up period to determine how long to take in getting all the threads up and running. For instance, if we had 5 threads and we set the ramp-up period as 50 seconds, JMeter takes 50 seconds to get all 5 threads running, or one thread every 10 seconds. It is necessary to maintain a decent ramp-up period to avoid unnecessarily large workloads when starting a test, but also short so that as tests complete running, others are up.


  1. Samplers
  2. Logical controllers

The controllers are responsible for test processing. Samplers initiate sending of requests to servers by JMeter and await server response, in the order they appear on the tree. Logical controllers allow customization of JMeter requests such as when to send requests to the server. You can also use a recording controller to log HTTP requests for use in the testing script.


  1. Graph results listener — access to response times
  2. View results in tree listener — displays in basic HTML and XML the sampler requests and responses
  3. Summary reports — maintains test reports for all requests in tables
  4. Real-time graph — is a line graph indicating the response time evolution for individual requests in a test

Listeners also file data for later use in a specified file. You can also choose configurations to save certain fields in either CSV or XML formats.



Building Your First Test Plan

We shall need to add a test plan that is in line with what we have covered about JMeter in the discussion above.

Step 1: Add a Thread Group

  1. Right-click on Test Plan
  2. Select Add
  3. Select Threads (Users)
  4. Select Thread Group

There are three important properties of thread groups that you need to keep in mind:

  1. Number of Threads (users): defines how many users JMeter will attempt to simulate. In this case, it was set to 50.
  2. Ramp-Up Period (in seconds): indicates the time through which JMeter distributes the start of the threads. In this case, it was set to 10.
  3. Loop Count: This defines the number of times tests are executed. This case study uses 1.

Step 2: Add an HTTP Request Defaults

  1. Select a Thread Group
  2. Right-click and select Add
  3. Select Config Element
  4. Select HTTP Request Defaults

In HTTP Request Defaults, under the Web Server section, fill in the Server Name or IP field with the name or IP address of the web server you want to test. Setting the server here makes it the default server for the rest of the items in this thread group.

Step 3: Enable HTTP Cookie Manager

  1. Select Thread Group
  2. Right click on the mouse and select Add
  3. Select Config Element
  4. Click HTTP Cookie Manager

Step 4: Include an HTTP Request Sampler

  1. Select Thread Group
  2. Mover over the option Add
  3. Move over the option Sampler
  4. Select HTTP Request

You will need to fill the Path with items to be accessed by each thread. In our case study, that has been set to /, which means all threads access the server homepage. There is no need to specify paths since those were already catered for under HTTP Request Defaults.

Step 5: Adding View Results in Table Listener

  1. Right-click the Thread Group
  2. Select Add
  3. Select Listener
  4. Select View Results in Table

Step 6: Run Your First Test Plan

What Your Results Mean

  1. Latency: indicates the time lapse between JMeter requests and initial server response
  2. Sample Time: time lapse in milliseconds for the full server request

In our sample case study, the sample time lies consistently between 128 and 164 Ms. Geographical distance is the most important factor that affects Sample Time if your server is sufficiently resourced. In the test case, the server responded well to 50 users making requests over 10 seconds. Now it is time to try increasing the load and see how well the system responds.

Load Increase

The server is clearly beginning to get burdened by requests. We can explore this information further by logging into the VPS and check resource utilization.

Our VPS resource utilization looks like so without JMeter test running:

Rerun the test on JMeter and monitor resource usage, our case study yielded the results in the below:

It is evident that there is substantial consumption of both CPU and RAM resources. To meet the increasing workloads, our servers need to either be optimized or we increase the CPU. We could also host the database in a different server. You can keep up the load till when there is substantial performance breakdown.



Follow me to keep abreast with the latest technology news, industry insights, and developer trends.