Introduction to performance tests using JMeter

Dominik Stolarski

JMeter is an open-source JAVA-based load testing tool for measuring and analyzing performance of services and applications. It simulates user behavior by sending requests to server. It can be used for testing variety of protocols and services like HTTP, HTTPS, SOAP / REST Webservices, FTP, JDBC, LDAP, SMTP, POP3, IMAP and many others.

Performance Testing

Performance tests check how the system behaves and performs under variety of load conditions. They can examine responsiveness, stability, speed and resource usage of application. Before running tests, it is necessary to determine system’s goals to be able to check if application works as expected and satisfactorily according to requirements.

Introduction to JMeter

JMeter is an open-source JAVA-based load testing tool for measuring and analyzing performance of services and applications. It simulates user behavior by sending requests to server. It can be used for testing variety of protocols and services like HTTP, HTTPS, SOAP / REST Webservices, FTP, JDBC, LDAP, SMTP, POP3, IMAP and many others. Application allows fast Test Plan recording. It has also non GUI mode and it’s easy to integrate it with Continuous Integration environment. You can run your script from a single machine but also in distributed mode. JMeter has built-in some reports and graphs which you can use for live reporting, but you can easily extend it’s abilities with external plugins. You can download them from https://jmeter-plugins.org/

Installing and running JMeter

Visit https://jmeter.apache.org/ page and download the latest version of JMeter. Extract downloaded file, go to the bin directory and run JMeter.bat file (Windows). What you see is an empty test plan – specification of settings and steps that JMeter will execute.  Let’s look at the components and settings that we can add to the test plan.

Components review

The most basic elements of each script are Thread Group and Samplers. I will also describe some other frequently used elements.

Thread Group is a component where you set up the number of virtual users to simulate the usage. One thread = one virtual user. You can also set the Ramp-up Period, Loop Count and Scheduler. Ramp-up Period is the time to load the whole number of users and the Loop Count is the number of iterations for each user to execute. Thanks to the Scheduler you can set the test duration or delay the startup.

Samplers are elements which generate requests and receive a response (E.g. HTTP request)

Assertions let us set the pass criteria for each sample. E.g. To check if response contains some text or the response code is as expected.

Timers define duration of the delay between requests. The purpose of timers is pausing the Virtual User for a certain amount of time to simulate the real usage of application.

Request Defaults let us avoid data duplication in tests and make scripts more maintainable. E.g. if each request has the same URL, you can set it once in Request Defaults. It defines the default values that the HTTP Request elements use

User Defined Variables is another one element that let us make scripts flexible and re-usable. You can set the URL, port, username, password etc. and parametrize your script.

Regex Extractor can be useful for extracting some information from the response and setting it as a variable to re-use it in other request (For example when testing an application that uses authentication tokens like CSRF/XSRF)

Cookie Manager manages cookies like a web browser. You can also manually add a cookie.

Listeners show the results of the samples. The results can be displayed in a tree, tables or graphs. They let us monitor the requests and analyze the received responses. The most basic and common listeners are „View Results Tree” and „View Results in table”.

To add any component to your test plan simply right click on the name of test plan select Add and choose the component.

Good practices

  • It’s good to use Request Defaults and User Defined Variables to make your scripts more maintainable.
  • If you use Script Recorder, review the recorded script and remove irrelevant requests.
  • Remember to use Cookie Manager if the application uses cookies.
  • For performance tests set up proper Number of Threads to simulate the real usage of application

Creating a script with built-in script recorder

You can use the JMeter Proxy to record your actions and save them as a test script.

Configuring script recorder is easy and requires only three steps.

1. Add Recording Controller to your Thread Group

2. Add HTTP(S) Test Script Recorder to your Test Plan

3. Configure the Browser to send traffic through the Proxy (go to proxy configuration and set up localhost and the same Port as in HTTP(S) Test Script Recorder.)

You can do it even easier with using template. You just need to click File > Templates and select 'Recording’.

Click 'Start’ in Script Recorder and now you can perform the scenario. All your actions will be saved in Recording Controller. When you finish, simply click the Stop button in the HTTP(S) Test Script Recorder and save your script. Remember to get rid of irrelevant requests from the recorded script.

Creating a basic script manually

Firstly, you need to add a Thread Group element by clicking right mouse button in 'Test Plan’ element to get the Add menu, and then select Add -> ThreadGroup. Then you need to set the basic values like number of virtual users users you want to simulate, Ramp-up period, etc. Let’s load 2 users in 1 second and run the script just 1 time.

Now you can set cookie support by adding an HTTP Cookie Manager to Thread Group. This will ensure that cookies are shared across all HTTP Requests. Select the Thread Group, and choose Add -> Config Element -> HTTP Cookie Manager.

While we are done with the basic settings we can start adding Http Requests. JMeter sends requests in the order that they appear in the tree. In the first request let’s set method to GET and requested URL to https://www.apache.org/. In the second one we can change the URL to https://www.apache.org/foundation/

We need a listener to see the results. Select the Test Plan, and choose Add -> Listener -> View Results Tree.

Now you can click 'Start’ button to run our script. Results will be displayed in Results Tree Report.

Running script and analyzing the results

You can run a test in the GUI or non-GUI mode. For a bigger number of Virtual Users you should use the non-GUI mode.

There are several useful reports and graphs that you can use, but the most common are Aggregate Report, View Results Tree and View Results in Table. You can also save the result to a file. The most useful and frequently used metrics are total number of executed requests, percentage of failures, average response time.

You can find them in Aggregate Report shown below.

Poznaj mageek of j‑labs i daj się zadziwić, jak może wyglądać praca z j‑People!

Skontaktuj się z nami