With the continuous growth of the number of services available online and a majority of potential clients or users opting for an online approach to those services, having a well optimised web application which can support a large number of concurrent users is a must these days. Failing to do so will substantially cut revenue and determine users to move to the next web app which can support their needs.
In order to measure an application’s performance and decrease the chances of downtime and failure, rigorous load testing must be done. That’s where JMeter steps in.
Introduction
JMeter is an open source testing software created by the Apache Software Foundation in 1998. The application is 100% Java based (runnable on most major operating systems) and it is used for load testing, analysing and measuring the performance of web services. It is also used for stress testing and to determine the maximum load capacity of a server.
JMeters highlights:
- It has the ability to test the performance of many different server/protocol types (HTTP, HTTPS, SOAP/REST, FTP etc.);
- Complete portability and 100% Java purity;
- It allows concurrent sampling by many threads and simultaneous sampling of different functions by separate thread groups;
- GUI mode (not so pleasant in appearance) allows the user to design the test plan faster and also perform debugging;
- Recording a set of test results after each run, results which can be viewed or replayed in offline mode;
- Support of variable parametrization, assertions (response validation), per-thread cookies, configuration variables and a variety of reports;
- A variety of plugins containing many useful features;
- Possibility of using scripts (BeanShell, BSF – compatible languages and JSR223 – compatible languages) provide great manipulation of data.
Important
Remember that JMeter is not a browser. It looks like a browser from a technical point of view (when we think of web services and remote services) but its purpose is to simulate browsers – multiple browser instances at the same time to be more exact.
Note: JMeter does not execute the JavaScript from a web application nor does it render any HTML elements in the page like a normal browser does.
Getting started
Having said all of the above, we can safely go forward to designing a test plan, running it, collecting and then analysing the results.
Creating the test plan
The first step is to download and unpack JMeter. Since it’s a pure Java application, no installation is needed. Run the jmeter.bat file on Windows or jmeter.sh on Mac OS or Linux variations.
The simplest way to create a test plan is to add a JMeter “HTTP(S) Test Script Recorder” to your WorkBench in GUI mode, set a proxy for the recorder, set the same proxy in a browser of your choice and start the recorder. Perform the actions in the browser which you want to be included in the test plan. All the traffic from your browser will go through the selected proxy and the various requests performed will be recorded.
While this might seem an easy and doable solution, it is often not the best option, since the user’s actions simulated are usually complex requests which use unique parameters generated on the fly and propagated throughout the test plan. It is recommended to use a web debugging tool like Fiddler or Wireshark to see exactly how each request is created, then create HTTP Samplers into JMeter to replicate those requests.
For example, you have Request A (https://example.app/createDocument/type) which creates a new document and Request B (https://example.app/documentID/addHeader) which adds a header to that created document.
In order to accurately simulate Request B, we need the documentID which is generated only when you perform the first request so in this case the solution is to add a post-processor to Request A which extracts the generated presentationID (with a regex or plain BeanShell code), puts it into a variable and calls it when forming the URL for Request B like this: https://example.app/${extractedVariable}/addHeader.
There isn’t a standard way to do this since every web-site is different that’s why it is essential to understand what each request does and what parameters are needed to accurately reconstruct those requests.
Running the test plan
After creating a test plan, it can be run in accordance with the client’s requirements either via GUI mode, which is not recommended since your computer will use extra resources and the reports will not reflect the actual results or via non GUI mode, from the command line.
Certain adjustments can be made to JMeter so the results come as close as possible to the results generated by users in a live scenario (see this article for JMeter configuration improvements).
Generating reports
In order for programmers to be able to fix performance issues and managers or product owners to make decisions, accurate test reports must be delivered. The vast selection of available JMeter plugins, 3rd party apps like BlazeMeter Sense or even Excel help test engineers to do so. Besides informative data tables generated after the tests are run, more graphical solutions for the reports are available, like a line chart displaying the number of hits to the server over a certain period of time and many more.
Conclusion
Even though Apache JMeter is a free application, there is a large community contributing to its continuous development ever since it has been released. This makes it an essential tool when it comes to rigorously testing the performance of a web application and delivering a reliable report afterwards.
Author: Dragos Campean
Sources:
