JMeter Stress Testing with BlazeMeter: A Tutorial

Performance testing is a crucial part of the software testing process. Understanding how our systems respond to different scenarios, and particularly what happens when they are pushed to their very limits, is of great relevance. We need to make sure they will keep operating, and above all, recover from possible errors. I will explain how to examine this with JMeter Stress Testing. We will see some examples using the testing tools JMeter and BlazeMeter.

What is Stress Testing?

Stress Testing is a type of software testing that evaluates how the software responds under extreme conditions. It verifies how robust a system will be, and its response capabilities and error handling when it is subjected to conditions where its normal functioning can be compromised.

Understanding the Importance of Stress Testing

The results provided by performing Stress Testing are very valuable. There is always the possibility that our system will be forced into errors due to an overload of requests or similar scenarios. We need to know what type of response our system will return, if it will recover, and up to what limit it will continue to be operational. Operationality is important for understanding the end-user experience.

📕 Related Resource: Learn more about Performance v. Load vs. Stress Testing

Running a Stress Test Using JMeter

Let’s see a basic configuration for a stress test using the tool Apache JMeter.

For this example, we will simulate multiple users interacting with an eCommerce website. The complete flow that a user will follow will be:

1. Navigate to the site.
2. Search for a product.
3. Try to checkout.

The target of this test is to check how many users can make requests simultaneously until the application starts to show performance problems. 

There are many ways to record a script for JMeter. You can record it though JMeter itself. Another possible way is to use BlazeMeter’s Chrome Extension.

After recording the steps required for the test, we need to configure the Thread Group. There are some settings to focus on:

• Number of threads (users): the amount of users we will be simulating.
• Ramp-up time: the time JMeter will need to start executing all the users that we set up.
• Loop count: the number of times the test script will be executed.
• Thread lifetime: this configuration determines the total duration of the test itself and how much JMeter will wait before starting the threads of the thread group.

In this exercise, we want to stress the server with 200 simulated users, with a ramp-up of 10 minutes. This means the server will reach 200 simultaneous users in 10 minutes.  We also configured the thread lifetime to be of 4 hours (in seconds), so we will be continuously hitting the server with 200 simultaneous threads in a span of 4 hours.

After running the test, we want to see the results.

JMeter offers some ways to visualize the metrics of the test result that will interest us for this exercise.

• Summary Report: a listener that presents a table with information for each request that was executed on the test. This information includes the number of samples that executed the request, the elapsed time, the percentage of errors and more.
• Response time graph: a listener that displays a graph of the response time of each request over time.
• Aggregate graph: a JMeter listener that generates a bar graph with response time for each request over time based on a .jtl file.

In this example of aggregate graph, we stressed a website with 200% of the expected user load (over 100 virtual users for an hour).

These solutions provided by JMeter allow us to obtain relevant data. However, they also consume resources from our device to generate them (in the same way the test is using the device resources to execute the simulated users). For this reason, we would be interested in executing this same script and generate a report using the tool BlazeMeter, which enables running performance tests in the cloud.

JMeter Stress Testing in BlazeMeter

Now we will see how to run our tests in BlazeMeter. First, we need to create an account and a project for our tests (you can always use the Default Project). If you are not familiar yet with the platform, I recommend reading these guidelines.

When creating a new test, we will be able to add our JMeter testing script. BlazeMeter recognizes the test as a JMeter test. We will prepare the Load Configuration to simulate a good amount of users sending requests to our website simultaneously.

When this is set up, we will run our test by hitting the “run test” button. The test will take some time to ramp-up all the users. After running the test we will obtain a full report. We also have the option to see an executive summary, where we can view timeline graphs that model many KPIs, like moments the response times were the longest.

We can also view which requests had the slowest responses by average response time. This will help us understand which type of requests will be affected the most by our stress testing.

Let’s take a look at another example where the system is not robust against the stress test:

In this case we tested against a website with 50 simulated users. We can see that as we increase the number of simulated users making requests, the response time increases but we also receive errors (mostly 5xx response codes, which are internal server errors). 

So, we can conclude that the website was not resilient to the stress test, and we would want to know what can we do about it:

What to Do with JMeter Stress Testing Results

There are several possible solutions when we want to reverse an adverse result in the report of the test we run. Sometimes we believe that by improving the hardware of our components the problem is already solved. But if we want to provide an efficient solution and identify exactly where the problems are generated, we must monitor all the components that are part of the application (app server, database server, load balancers, etc.) when executing the test. This way we can separately identify response times and resource consumption.  

Conclusion

To sum up, Stress Testing is a practice that I strongly suggest. It allows us to check the behavior of a system when it is in its most critical moments and provides us with information of great importance. And as we have seen, we can apply this practice in a simple way using the mentioned tools, to obtain reports quickly. I would definitely recommend studying and trying out this practice to any tester.

START TESTING NOW