Apache JMeter is a Java-based stress testing tool developed by the Apache organization. For stress testing software, it was originally designed for web application testing but has since expanded to other testing areas. It can be used to test static and dynamic resources such as static files, Java servlets, CGI scripts, Java objects, databases, FTP servers, etc. JMeter can be used to simulate huge loads on servers, networks or objects to test their strength and analyze overall performance under different stress categories.
Additionally, JMeter can do functional/regression testing of your application by creating scripts with assertions to verify that your program returns the results you expect. For maximum flexibility, JMeter allows the use of regular expressions to create assertions.
Next, I will stress test my local SpringMVC. The stress test object is a few random webpage links. These links are written in a text file and will be read randomly during the stress test.
1. Create a thread group
Why create a thread group? The reason is simple, because we want to simulate multiple threads (users) to access.
In the thread properties section, the number of threads is how many threads to start. I fill in 100 here. Ramp-Up Period (in seconds) indicates how much time is allowed between threads. The unit is seconds. For example, if you fill in 1, then 1/100 =0.01 means that the website is requested every 0.01 seconds between 100 threads.
Number of loops: 100 threads are run once, and the number of loops is how many times such a request process runs. I filled in 100 for the test here.
Every time you modify a setting, don't forget to save it.
2. Set the request server, pressure link and other information
The natural next thing is, what is the address of the website we want to test? What is the link? So now let's set this information up. Right-click on the thread group we just created, and in the pop-up menu, select Add->Sampler->Http Request, and the following interface will pop up:
Path: If you are just stress testing a link, it is ok to fill in a link directly, such as http://localhost:8080/SpringMVC/greet?name=lisi, but this is not the case in most cases, we need more As mentioned at the beginning, we need to save multiple links to a text file, and then randomly read them for stress testing. We can do it like this:
In the Select a function drop-down list, select _StringFromFile, and then create a new test file D:\software\Jmeter-2.13\data\test.txt in the local machine, in the value of the first line (you can also not be in the first line) Fill in the path of the test file, as shown below:
Then click the "Generate" button, a string such as: ${__StringFromFile(D:\software\Jmeter-2.13\data\test.txt,,,)} will be generated in the text box on the left of the generate button
In the test.txt test file, we write a URL link per line, in the following format:
Note that there is no such information as http://localhost:8080 in front of each line, because we have filled in the server address as localhost and the port as 8080, so there is no need to fill in the same prefix for each url; in addition , the above url format is just an example, indicating the part after the domain name.
In this way, when we are not requesting, the url will be randomly selected from test.txt for stress testing.
Another thing worth noting is that if there is Chinese in the parameters, garbled characters may appear during operation. At this time, you need to pay attention to the encoding settings in Jmeter and the encoding of the web page you want to request.
The options below the path text box can be made by default. Use multipart/form-data for HTTP POST is when there is an attachment in the request. Generally, it is not necessary to select it.
3. View the running results
Right-click on the thread group and select Add->Listener->Query Results with Tables in the pop-up menu, as shown in the following figure:
4. Run
Of course, before running, please save all changes. The result table after running is as follows:
The properties are as follows:
Sample: the sequence number of each request
Start Time: The start time of each request
Thread Name: the name of each thread
Label: Http request name
Sample Time: The time spent on each request, in milliseconds
Status: The request status, if it is a tick, it means success, if it is a cross, it means failure.
Bytes: the number of bytes requested
If Status is a fork, it is obvious that the request failed, but if it is a tick, it cannot be considered that the request must be completely successful, because it depends on whether the number of bytes in Bytes is the normal size of the requested web page, if not. It means that packet loss has occurred, and it is not completely successful.
There are a few more parameters below:
Number of samples: that is, the number of requests mentioned above. In the case of success, it is equal to the number of concurrent times you set multiplied by the number of loops
Average: Average time per thread request
Latest sample: Indicates when the server responded to the last request
Deviation: Changes in server response times, the size of a measure of dispersion, or, in other words, the distribution of the data (which I don't quite understand).
Of course, you can also view the result tree to see the request and request response details, as follows:
5. Download the configuration file
The configuration file generated by the above example can be obtained by downloading the attachment "".
Attachment: Terminology
Thread group: Each task in the test needs to be processed by a thread, and all our subsequent tasks must be created under the thread group. You can create it in "Test Plan (right-click) -> Add -> Threads(Users) -> Thread Group", and then there are several input fields in the Thread Group panel: number of threads, Ramp-Up Period(in seconds ), the number of cycles, where Ramp-Up Period (in seconds) indicates that all threads are created within this time. If there are 8 threads, Ramp-Up = 200 seconds, then the thread start time interval is 200/8 = 25 seconds. The advantage of this is that it will not put too much load on the server at the beginning.
Sampler: It can be considered that all testing tasks are undertaken by samplers, there are many kinds, such as HTTP requests.
Assertion: Judge whether the request result returned by the sampler is correct.
monitor: Its function is to display the request result of the sampler, count some data (throughput, KB/S...), etc.
Article source: http://blog.csdn.net/hshl1214/article/details/50611910