Skip to content

Stress testing with JMeter

javikalsan edited this page Mar 3, 2020 · 6 revisions

What is JMeter?

The Apache JMeter™ application is open source software, a 100% pure Java application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions.

Official website

JMeter github repository

What can we do with JMeter?

Ability to load and performance test many different applications/server/protocol types:

  • Web - HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, …)
  • SOAP / REST Webservices
  • FTP
  • Database via JDBC
  • LDAP
  • Message-oriented middleware (MOM) via JMS
  • Mail - SMTP(S), POP3(S) and IMAP(S)
  • Native commands or shell scripts
  • TCP
  • Java Objects

Installation

To install JMeter is recommended download latest stable versions rather than use operating system repositories to get latest features and improvements.

In the same way is recommended install the Plugins Manager to extend easily the features of the tool, for example, to add parallelization to concurrence.

JMeter offical plugins website

Configuration

To generate a new configuration file, which will be used from the command line passing his filesytem path as a parameter, we'll use a real example to explain how to configure basic settings. Is important highlight that the execution, althought we can test via GUI, is highly recommended use the command line. A reason to execute the Test Plan from GUI is to check configuration settings, for example, asserting HTTP status, content responses, etc.

Real use case: JMeter Test Plan for aqueduct analytics microservice

With the aim to check the response evolution with user concurrence and measure infrastructure healthy limits to cover current user concurrency needs we created a JMeter Test Plan to simulate:

4 concurrent users requesting in parallel defined microservice endpoints with a delay of 300ms between each request.

jmeter-overview Aqueduct analytics Test Plan general overview

Test Plan

Establish a name for the configuration file we are going to create, from the window menu:

File -> Save Test Plan as

Is recommended save the new changes in our Test Plan frequently.

HTTP Request defaults

The endpoints are sharing the same URL schema, so, we can create a shared configuration. This will be useful if URL change or we wants to switch to other environment URL based. To add a share configuration we have to right click over the Test Plan tree element of the left sidebar and follow the menu:

Add -> Config element -> HTTP Request Default

Only 2 fields will be enough for this use case:

Protocol [http]: https
Server Name or IP: production-api.globalforestwatch.org

The above configuration is declaring for all endpoints, HTTP Request JMeter object, this base URL: https://production-api.globalforestwatch.org

Thread Group

To group the endpoints with the same concurrent parameters we have to use the JMeter object Thread Group and put inside all endpoints. To create a new Thread Group right click over the Test Plan tree element:

Add -> Threads (Users) -> Thread Group

The configuration fields to fill in the Thread Properties section will be:

Number of threads (users): 4
Duration (seconds): 120

Number of threads defines the number of users which will be simulated and Duration how many seconds the concurrency will last.

Once we have created the Thread Group we can easily drag and drop the endpoints (HTTP Request) into the Thread Group to apply the defined concurrency to them.

HTTP Request

Next we will see how an endpoint is created, right click over the Thread Group to create the endpoint directly here and:

Add -> Sampler -> HTTP Request

http-request-example HTTP Request configuration form example

As we have a shared settings object: HTTP Request Defaults the fields Protocol and Server Name can be empty.

We must fill:

Method: GET
Path: /v1/aqueduct/analysis/cba/widget/impl_cost
Parameters: All the parameters needed

Usually all the fields are quite intuitive, so being familiar with HTTP protocol will be easy identify the options we need to cover other use cases.

Parallel Controller

To parallelize the concurrency and launch the requests simultaneously will add a JMeter Plugin called Parallel Controller & Sampler via Plugin Manager, it's as simple as open the Plugin Manager search Parallel Controller & Sampler, mark the checkbox of the Plugin and click "Apply Changes and Restart JMeter", don't forget to save the changes before.

Once the plugin is installed we'll add the corresponent object right clicking over Thread Group and:

Add -> Logic Controller -> bzm - Parallel Controller

For this use case no configuration is required, we only need to move our HTTP Request objects into bzm - Parallel Controller object to parallelize them.

Constant timer

To finish the configuration of the use case we have to add a delay between requests in order to improve the simulation, a scenario where the users or the application behavior add some delay. We'll use Constant Timer object to add the delay right clicking over Thread Group and:

Add -> Timer -> Constant timer

and set:

Thread delay (in milliseconds): 300

To validate the configuration we can use a Validate functionality we can find right clicking over Thread Group.

Execution

Once we have our Test Plan configuration ready we'll use the command line to execute it.

Use the following command to execute a Test Plan using the file.jmx JMeter configuration file:

jmeter -n -t /path/to/jmeter/configuration/file.jmx -l /path/to/result.csv -e -o /path/to/result/html/report/folder
-n, --nongui
		run JMeter in nongui mode

-t, --testfile <argument>
		the jmeter test(.jmx) file to run

-l, --logfile <argument>
		the file to log samples to

 -e -o [Path to web report folder]

run jmeter --help to know more options.

The command executed will generate a csv file and a html report with the results. Below is shown some graphs generated by the html report:

response-time-percentiles Response time percentiles

response-times-percentiles-over-time Response time percentiles over time

time-vs-threads Time VS threads