January 9, 2013 at 01:20How to create a load test using Apache Jmeter
In this post, I will describe how to create a load test of a web application using the load testing tool developed by the Apache Jakarta Project - JMeter .
JMeter is a very powerful load testing tool with the ability to create a large number of requests at the same time due to parallel work on several computers. It supports plugins with which you can expand the functionality. The tool was used by me earlier when testing large Internet banking. You can download JMeter at http://jmeter.apache.org/download_jmeter.cgi , to start, go to \ bin \ jmeter.bat.
Having launched the program, on the left we see 2 points - Test Plan and WorkBench. Add Thread group to Test plan, for this you need to right-click on Test plan - Add - Threads (Users) - Thread group.
Next, inside the Thread group, create test settings elements, right-click on Thread group - Add - Config Element and select 4 items in turn:
The next thing to do is add the HTTP Proxy Server . Right-click on WorkBench - Add - Non-Test Elements - HTTP Proxy Server. In the HTTP Proxy Server settings, specify any unique port address (I always use 8089) and uncheck Capture HTTP Headers.
Now go to any browser to configure the proxy server on it. I prefer Firefox for such purposes. In the network settings, we indicate the use of the proxy and enter HTTP Proxy - localhost, port - 8089 used by us. Do not forget to remove the exception for localhost.
We return to Jmeter in the HTTP Proxy Server and click the Start button at the very bottom. Now back to the browser, and load all the interfaces that need to be load tested.
Go back to Jmeter and click Stop in the HTTP Proxy Server.
Next, we clear the project with unnecessary information. Some packages refer to third-party services for which we do not need to create a load. They need to be deleted. To do this, iterate over all of them and see what Server Name or IP value is indicated. If the server name is not related to the tested resource, we will not create additional load on it. We delete such url (by pressing del):
And we leave such:
We add view elements to the Thread Group in turn. Right-click on Thread Group - Add - Listener - Graph Results , Aggregate Report , View Result in Table and View Result Tree .
The last setting before starting is to specify the number of users (Number of Threads) and the number of iterations (Loop Count) by clicking on the Thread Group and setting the appropriate parameters.
All is ready. We start the test by clicking the green triangle on the top panel and open any of the viewing elements - we have online statistics. Since we set the Loop Count - Forever, click Stop after testing. Now, in order about each view item.
Graph Results displays the result in a graph:
Values provided in milliseconds.
Data - response time of each individual data unit i.e. every verified url.
Average - average response time, objective graph of load changes.
Median - median value (used in statistics, I do not use these data).
Deviation - error, standard deviation.
Throughput - throughput of executed requests.
For work, the values Average and Throughput are enough, which will display the load on the web server and the bandwidth of the requests. The graph above shows that the response time is approximately 200ms and does not increase, that is, the server normally withstands the load of 3 virtual users. But what happens if there are 30 of them:
The response time increases significantly, the higher the throughput of requests (less than milliseconds), the more time it takes for the server to process.
By the way, at the time the test is running, the site really lays down, so you should not check the load of third-party Internet resources, since we can be mistaken for ddosers.
Aggregate Report will display statistics for each individual url separately.
In the Average column we see the average response time, it is logical to assume that the larger it is, the greater the load on this url.
View Result in Table displays the result in the form of a table, the time is indicated here, as well as the status (successful / not successful).
The bottom line is an error. Why exactly it arose can be checked in the View Result Tree . Let’s go there and find this line. Now we see the cause of the error.
This completes the testing. During it, we tested one of the web applications for load, and we got very visual results.
JMeter is a very powerful load testing tool with the ability to create a large number of requests at the same time due to parallel work on several computers. It supports plugins with which you can expand the functionality. The tool was used by me earlier when testing large Internet banking. You can download JMeter at http://jmeter.apache.org/download_jmeter.cgi , to start, go to \ bin \ jmeter.bat.
Having launched the program, on the left we see 2 points - Test Plan and WorkBench. Add Thread group to Test plan, for this you need to right-click on Test plan - Add - Threads (Users) - Thread group.
Next, inside the Thread group, create test settings elements, right-click on Thread group - Add - Config Element and select 4 items in turn:
- HTTP Authorization Manager . We use it when you need to conduct a test with user authorization. Click Add and fill in the Base URL of the resource, specify the username and password of the account in User and Password.
- HTTP Cookie Manager will automatically save cookies.
- HTTP Header Manager will add header information to each recorded packet, for viewing which it will be necessary to “expand” the line (the tree in the screenshot will be created by us a little later). The title can be edited.
- HTTP Request Defaults . The parameters of this setting (such as the name and port of the server, queries with the parameter, etc.) will be applied to all elements located in the test plan that do not have their own settings.
The next thing to do is add the HTTP Proxy Server . Right-click on WorkBench - Add - Non-Test Elements - HTTP Proxy Server. In the HTTP Proxy Server settings, specify any unique port address (I always use 8089) and uncheck Capture HTTP Headers.
Now go to any browser to configure the proxy server on it. I prefer Firefox for such purposes. In the network settings, we indicate the use of the proxy and enter HTTP Proxy - localhost, port - 8089 used by us. Do not forget to remove the exception for localhost.
We return to Jmeter in the HTTP Proxy Server and click the Start button at the very bottom. Now back to the browser, and load all the interfaces that need to be load tested.
Go back to Jmeter and click Stop in the HTTP Proxy Server.
In a situation in which you need to edit the host settings for those packets for which they are different from HTTP Request Defaults, it is more convenient to do this as follows. Save the project (File - Save), and close it. Open the saved * .jmx file with Notepad ++ (or Notepad) and delete the values of all lines:domainportprotocol
and all other parameters that need to be changed. Save the file and open it in Jmeter. We return values in HTTP Request Defaults. Now they apply to those requests that have their settings specified.
Next, we clear the project with unnecessary information. Some packages refer to third-party services for which we do not need to create a load. They need to be deleted. To do this, iterate over all of them and see what Server Name or IP value is indicated. If the server name is not related to the tested resource, we will not create additional load on it. We delete such url (by pressing del):
And we leave such:
If in the url we need to register a link with a parameter or change the current one, click on the url into which we need to insert (edit) the parameter. In the column Parameters we make the necessary changes.
If it is necessary to specify parameters through variables, add to the Thread Group User Defined Variables by right-clicking on it - Add - Config Element - User Defined Vaiables. Add variables by specifying their Name and Value. Now we specify the parameters as variables in a format in the format $ {VariableName}.
We add view elements to the Thread Group in turn. Right-click on Thread Group - Add - Listener - Graph Results , Aggregate Report , View Result in Table and View Result Tree .
The last setting before starting is to specify the number of users (Number of Threads) and the number of iterations (Loop Count) by clicking on the Thread Group and setting the appropriate parameters.
You can distribute testing by running multiple copies of the test on different hosts, but managed from one central one. This increases the load and is done as follows:
- On the server computer, run the file /bin/rmiregistry.exe. If the assembly does not have this file, download it through a search engine. If, at startup, the file swears at the absence of the jli.dll library, download it also (for example, here www.search-dll.com/dll-files/download/jli.dll.html ) and upload it to windows / system32 (system64).
- We open /bin/jmeter.properties via Notepad ++, here you need to remove the comment from the line server.rmi.create = false, removing the “#” character at the beginning of the line.
- Run /bin/jmeter-server.bat.
- On the client, in the /bin/jmeter.properties file, you need to specify the hosts in the remote_hosts line, for example, remote_hosts = 10.1.100.101, 10.1.100.102, 10.1.100.103, after which you need to restart Jmeter.
- We start the test by selecting the menu item Run - Remote Start (to start one host) or Run - Remote Start All (to start all hosts).
All is ready. We start the test by clicking the green triangle on the top panel and open any of the viewing elements - we have online statistics. Since we set the Loop Count - Forever, click Stop after testing. Now, in order about each view item.
Graph Results displays the result in a graph:
Values provided in milliseconds.
Data - response time of each individual data unit i.e. every verified url.
Average - average response time, objective graph of load changes.
Median - median value (used in statistics, I do not use these data).
Deviation - error, standard deviation.
Throughput - throughput of executed requests.
For work, the values Average and Throughput are enough, which will display the load on the web server and the bandwidth of the requests. The graph above shows that the response time is approximately 200ms and does not increase, that is, the server normally withstands the load of 3 virtual users. But what happens if there are 30 of them:
The response time increases significantly, the higher the throughput of requests (less than milliseconds), the more time it takes for the server to process.
By the way, at the time the test is running, the site really lays down, so you should not check the load of third-party Internet resources, since we can be mistaken for ddosers.
Aggregate Report will display statistics for each individual url separately.
In the Average column we see the average response time, it is logical to assume that the larger it is, the greater the load on this url.
View Result in Table displays the result in the form of a table, the time is indicated here, as well as the status (successful / not successful).
The bottom line is an error. Why exactly it arose can be checked in the View Result Tree . Let’s go there and find this line. Now we see the cause of the error.
This completes the testing. During it, we tested one of the web applications for load, and we got very visual results.