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 optimized 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.
To measure an application’s performance and reduce the risk of downtime and failure, you must conduct rigorous load testing. 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). It serves for load testing, analyzing, and measuring the performance of web services. Additionally, it is employed for stress testing and determining a server’s maximum load capacity.
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 allows you to view or replay the results 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. As it’s a pure Java application, there’s no need for installation. 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 that you wish to include in the test plan. The selected proxy will channel all your browser traffic, capturing the various requests made during the process.
While this might seem an easy and doable solution, it is often not the best option. The user’s actions simulated are usually complex requests which use unique parameters generated on the fly and propagated throughout the test plan. Using a web debugging tool like Fiddler or Wireshark is recommend to observe the precise creation of each request. Then create HTTP Samplers into JMeter to replicate those requests.
For example, you have Request A () which creates a new document and Request B () 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. 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: {extractedVariable}/addHeader.
There isn’t a standard way to do this since every website is different. Hence, comprehending the purpose of each request and the required parameters is crucial for accurately reconstructing these requests.
Running the test plan
After creating a test plan, you can run it to meet the client’s requirements either through GUI mode—though this isn’t recommended due to the extra resource usage and reports not reflecting 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 from generating informative data tables after running tests, there are additional graphical solutions available for the reports. Like a line chart displaying the number of hits to the server over a certain period of time and many more.
Conclusion
Despite being a free application, Apache JMeter has benefited from a large and active community that has contributed to its ongoing development since its release. This makes it an essential tool when it comes to rigorously testing the performance of a web application and delivering a reliable report afterwards.
Article written by Dragos Campean
This article was originally published here.
Sources:
