How to Perform Load Testing Using JMeter

How can this be prevented in the future? Is there a way to test applications for such high demand? Can we simulate thousands of users accessing the app at once during testing? Luckily, the answer is yes.

Introduction to load testing

Applications undergo extensive testing during development. However, testing manually or automatically usually shows how the app works for a single user, not how it would perform with many users using it at the same time. To test this, it's necessary to simulate multiple users making requests simultaneously. This helps identify if the server can handle the load or if there are issues with processing requests and providing proper responses.

To make sure applications perform well in real-life conditions, you can conduct various types of performance tests. If you want to know how much load an app can endure, the answer lies in load testing. 

Load testing is a type of performance testing that measures how an application performs under heavy user activity and various conditions. It applies to all kinds of applications, whether mobile or web and covers both frontend and backend. Through load testing, a Quality assurance engineer assesses how many users can use the app simultaneously without encountering any issues.

You might ask yourself if load testing will give you a magic number of users that an application can handle. Well, the answer is no. Analyzing load testing results isn't as simple as labeling them as expected or not. There are various factors that must be considered to determine the app's capacity, and even then, the answer won't be a single, definite number.

Starting with Apache JMeter

Before conducting load testing, you need to make a few decisions. The first is selecting the tool you'll use. Personally, I recommend Apache JMeter, an open-source software made specifically for load testing and measuring performance. It's widely used because it offers extensive options for designing test cases, provides several options for result analysis, and benefits from a large and active community for collaboration.

JMeter offers an intuitive GUI for writing and debugging tests. However, when actually running tests, it's recommended to use CLI mode (Command-line mode) for better resource handling and more accurate results. All run results will be generated as CSV or XML files, and JMeter also generates an HTML report containing all necessary information for conducting a thorough result analysis.

Write your first test with JMeter

Once you've downloaded JMeter and the machine's setup is ready, it's time to write your first test. When you open the JMeter GUI, you'll see an empty test plan. Rename this test plan to correspond with the project you're developing load tests for. Naming the test plan is one of the first steps toward creating a clear and concise testing environment. It ensures that anyone who opens your project understands its contents.

The goal of load testing is to simulate user interaction with an application. To do this, you should create some users. So let's do it. Add a Thread Group within Threads (Users) to create a new configuration for simulating user behavior.

The Thread Group controls the number of "users" (threads), allowing you to manipulate the application's load. Besides the number of users, you can manipulate their access to the app as well. Some applications need to withstand prolonged activity from a steady number of users, while others must handle bursts of massive user entries in short periods. This flexibility helps you simulate various scenarios, ensuring your application can manage different types of user interactions.

Once the user group is defined, you can start defining the test. To specify the action the “user” will perform, you need to add an HTTP request. This request contains all the necessary details and data for the request that's going to be performed and has to be added to the Thread Group. Requests should be made in the order the actions are performed; for example, if logging in is the first action, place that request first. To avoid overloading requests, you can predefine values such as URLs and variables. 

All elements must be added within the Thread Group in order for them to be applied to it. If we assume that one base URL is needed throughout the application, define it in the HTTP Request Defaults Config element. To make it even more uniform, create a variable for it in the User Defined Variables Config element.

To add a variable, simply click on “Add” at the bottom and define its name and value. Then, use this value from now on everywhere where it’s needed to reduce time and effort in case change is needed. Variables in JMeter are called with: ${variable_name}.

Now, use this variable within HTTP Request Defaults:

Once the necessary pre-definitions are made, you can create the requests. To do this, you need to know the application's API calls and the required parameters for executing it. Each request should be named according to the action it performs.

With the base URL defined, it doesn't need to be specified for each request; HTTP Request Defaults will handle that. What needs to be defined is the protocol, method, and path to which the request is being sent. Parameters that have to be sent within the request can be sent as a file, defined parameters, or in a free format such as JSON.

When writing tests and debugging, use the Run command from the GUI, but once you’re sure the tests are ready for serious execution, use the CLI.

Save the test plan in .jmx format to be able to run it with the command:

run sh jmeter -n -t nameoftestplan.jmx -l nameofresultsfile.jtl*

*nameofresultsfile.jtl - this file doesn’t have to be created, it will be created automatically

Analyzing the results

To analyze and verify the test outcomes, you should add some listeners. JMeter offers a variety of listeners, each providing specific analytical value. Some are more graphical, while others are more analytical. Choose wisely based on the value it'll bring you, and don't be afraid to play around with them until you find what fits you the best. 

In this example, I’ll show you a Response Time Graph listener and explain it briefly. 

The Response Time Graph gathers data during execution, creating a graph with execution time on the X-axis and the response time of requests (in milliseconds) on the Y-axis. Each test has its graph entry, with an according legend at the bottom. 

This test plan includes a Thread group of 200 users with a ramp-up period of 10 seconds. There are 14 tests in total, including login, 12 specific feature tests, and logout – all covered in the Main features group.

You can see here that some requests are approaching 6000 ms, and this exact number is important because it’s the critical number in response time analysis. Studies show that users are likely to stop using an application if they have to wait 6 seconds or more for a response. In our case, this means that at least one of the 200 users who’s waiting for 6 seconds to complete an action, will probably exit and stop using the app. This scenario needs to be revisited by the development team, refactored, and tested again.

A final takeaway

Load testing is not your day-to-day type of testing, but its approach can increase the application’s worth and make it better for users, with less fixing needed in production.

After learning the basics, you’re ready to dive into the practical use of JMeter and its functionalities in order to execute load testing. Stress your application, but don’t let it stress you!