When it comes to web products, load testing plays an instrumental role in analyzing and measuring the performance of the offered features (or services) under different load conditions. Consider a scenario where the application performs well under sub-optimal (and optimal) workload but its performance deteriorates when the workload is too high! Well, it could have a major impact on the user-experience since the requests might take much longer to process than expected.
This is where Apache JMeter, Java-based open-source software can play a pivotal role in load testing the functional behavior and analyzing the performance to take subsequent corrective measures. JMeter 5.4 – the latest version of JMeter was introduced in December 2020. JMeter 5.4 has a significant number of bug fixes, improvements, as well as under-the-hood changes that enhance the overall JMeter experience.
In this blog, we deep dive into the notable improvements and enhancements that were introduced in JMeter 5.4. Along with this, we also look how the capabilities offered by JMeter 5.4 can be further enhanced by scaling out your JMeter test on the cloud with RedLine13.
Table of Contents
Downloading and installing JMeter 5.4 is super easy, as it takes only a few clicks to install the latest version of JMeter. To download JMeter 5.4, visit the JMeter Download page on the official website of JMeter and click on the relevant package as shown below:
When downloading, it is recommended to verify the signatures using the KEYS file. Once you have downloaded JMeter 5.4, head over to the ‘bin’ folder in JMeter package [ e.g. C:\JMeter_Download_Location\bin\ ] on the command-line and run the command jmeter –version to do a quick version check.
Now that we have JMeter 5.4 on the host machine, let’s look at some of the major feature improvements and new introductions in JMeter 5.4 that aid in enhancing the JMeter experience.
Though JMeter 5.4 is pre-dominantly around bug fixes, there has been an introduction of a few new features and enhancements. The official JMeter changelog gives insights into the major changes in JMeter 5.4.
Here is the list of major features and enhancements introduced in Apache JMeter 5.4 – the widely preferred open-source load testing tool:
For starters, GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a more understandable description of the data in the API, making it easier for API to evolve over a period of time. Further details are available on GraphQL home page.
JMeter and GraphQL is a powerful combination when it comes to applying load test on GraphQL. JMeter lets you simulate the user-flow from the front-end of app by issuing a number of simultaneous (or concurrent) requests. Prior to JMeter 5.4, you could test GraphQL using the normal HTTP Request sampler but it was necessary to define a JSON object with the ‘query’ attribute. There was additional overhead, as the value had to be escaped for enabling the translation of GraphQL queries to JSON.
The HTTP Header Manager lets you customize what information JMeter sends in the HTTP request header. User-Agent, Pragma, Referer, etc. are some of the properties that can be sent with the request header. Prior to JMeter 5.4, it was mandatory to add HTTP Header Manager for sending the Content-type header.
The additional overhead is a thing of the passé with Apache JMeter 5.4. Shown below is a short demo of the GraphQL HTTP Request sampler where we read the weather of London using the openweather.org:
We use the parameters – q: city-name and APPID – <unique_app_id> to get the weather data via HTTP request:
The HTTP status code is 200 which indicates that the HTTP request was completed successfully. Here is the response header and response data which indicates that the weather data for London was fetched successfully.
Here is the response body and response headers in the JSON format:
On receiving the request, browser gets the HTML page, parses the page, and retrieves the embedded resources with each HTTP request.
In order to reduce the load time of an already visited website, the web browser caches files such as documents, images, CSS style sheets, fonts, etc. that make up the website. In case there is any update on the content of the website, the browser downloads only the updated content from the server and fetches the remaining (unchanged) content from the Cache.
When load testing is performed, static resources such as images, CSS Stylesheets, HTML, etc. are not downloaded, unless JMeter is explicitly informed (or configured) to download the same. JMeter not only provides config elements for mimicking the browser behavior but also lets you simulate the browser caching behavior via the ‘Cache Manager’.
JMeter provides URL filters that lets you retrieve the embedded resources. However, excluding the ‘external resources scope’ was a tad difficult in earlier versions of JMeter as you had to come up with a negative regular expression. JMeter 5.4 provides separate input fields:
- URLs must match – Specify the domains for which embedded resources have to be downloaded.
- URLs must not match – Specify the domains that are unwanted or have to be ignored.
The above setting also applies to the HTTP Request Sampler and HTTP Request Defaults configuration elements.
The HTTP(S) test script recorder lets you create a Test Plan by running a few steps. For a quick recap on Test Recorder in JMeter, please refer to our earlier blog on JMeter recording.
As seen in the JMeter Changelog, the HTTP(s) Test Script Recorder underwent significant changes. You now have the flexibility to use the suffix and format string when recording.
Along with this, you can also toggle the detection of GraphQL when recording the test.
In versions earlier to 5.4, the available options for Backend Listener were limited to GraphiteBackendListenerClient and InfluxdbBackendListenerClient.
Figure 1 BackEnd Listener in JMeter 5.0
In addition to the above mentioned options for BackEnd Listener, a new implementation option ‘InfluxDBRawBackendListenerClient’ is available in JMeter 5.4
Figure 2 Addition of InfluxDBRawBackendListenerClient in JMeter 5.4
The InfluxDBRawBackendListenerClient listener allows the storage of ‘raw’ metrics. With this, you have individual results – elapsed time, start time, connect time, latency, etc. for each sampler. As shown above, this lets you send the raw results to the Influx DB Backend.
Load testing on a local environment can have scalability issues due to which it is not suited for commercial (or large scale) web projects. This is where JMeter cloud load testing by Redline13 can help in realizing the benefits offered by Apache JMeter.
With JMeter cloud load testing by Redline13, you can scale JMeter tests to any size – 1,000 users, 10,000 users, and even 1,00,000+ users. Redline13 uses Amazon AWS infrastructure for running existing load tests on the cloud. Apart from Amazon AWS setup for Redline13, no changes have to be done in the JMeter tests (which are in the .jmx format).
The JMeter test which we executed on the local machine can be run on the infrastructure provided by RedLine13 without any changes. Here is the execution summary of the test executed on RedLine13:
With the execution summary, it also provides Overview metrics that indicates the JMeter threads run per second, Average JMeter Thread Elapsed Time, and more.
JMeter 5.4 includes a lot of bug-fixes & performance improvements in comparison to the previous versions of JMeter. In this blog, we had a look at some of the new features introduced in JMeter 5.4. Redline13 can be used for realizing scalable JMeter load tests, something that cannot be achieved with a local JMeter setup.