1. Concepts of basic JMeter interfaces and components
Now we can see the main interface of Jmeter. The following describes the functions and functions of the main components in Jmeter. First, let's take a look at the concept of Jmeter component classification as shown in the figure
1. threads: This component is mainly used to control the number of Threads generated during Jmeter concurrency. There is only one component (Thread Group) in its next menu. It can be understood that each thread is a virtual user.All other types of components must be subnodes of (Thread Group) nodes.
2. configuration Unit: It works with the Sample component and is mainly used to configure how the Sample can initiate a request to access the server. The main feature of this item is that some Sample configurations can be put in one element for ease of management, the configuration unit has a scope. The same relationship between the scope and the tree, the larger the scope of the parent node, the closer it is to the leaf node.
The smaller the scope, the higher the scope configuration can be rewritten.
3. Timer: This is mainly used to adjust (Thread Group) and control the interval between each thread running the test logic (for example, sending a request. Of course, there are many types of timers below. Their main function is to adjust the time interval, but the policies of each component are quite different.
4. The pre-processor and the post-processor are similar to a HOOK and execute some script logic before and after the test execution. I have not used this component yet, but the general function is like this. It is not a key component.
5. Sample: the Sample may not appear in the preceding figure. You must add it to the ThreadGroup.
Sample indicates that the client sends a request in a certain format or specification to the server. Therefore, you can see a variety of samples, including two Http-related. Generally, HttpClient is more efficient.
6. Assertion: it means to determine whether the returned results meet expectations after the Sample completes sending the request.
7. listener: This component is different from the listener for Web programming at ordinary times. It is a component that captures data during the runtime along with the Jemeter test, the aggregate report component is often used, from which key test data such as TPS and response time can be counted.
II. Instance operations
Add a ThreadGroup component under TestPlan to set the parameters of the thread group component.
Key parameter explanation:
Thread count: maximum number of threads used for testing.
Ramp-Up Period: the time when Jmeter reaches the specified maximum number of threads.
Number of cycles: if it is Forever, the threads in the thread Group will continuously test the system. Of course, you can also set the number of tests per thread. After the specified number of times is completed, this thread will automatically exit the Thread Group.
Scheduler: it is mainly used to specify the time information of the test. For example, from the start time to the start time, if the test is not completed at the specified time, the test will also be stopped.
Next, add the Sample component under the thread Group. Let's add an HTTP Request HTTPClient component and set the attributes as shown in the following figure:
Finally, add the listener component: Aggregate Report!
Well, a simple stress test example is completed. You can see some performance result parameters in the report. The following is a more complex example.
III,Response assertions: performs assertion verification on the server response.
(1) scope of application: main sample and sub sample, main sample only, sub-sample only, jmeter variable
For the scope of application, it is sufficient to select "main sample only", because we only have one request. However, when we send a request, we can trigger multiple server requests, similar to ajax, so there are different main sample and sub-sample.
In addition, if the redirection request is selected and "follow redirection" is selected, both requests are sub-sample. The redirected request (the second request) is main-sample.
For more information about main sample and sub sample, see this post.
Http://stackoverflow.com/questions/28214936/jmeter-in-which-scenario-i-can-use-main-sample-or-sub-sample-or-both-for-te
(2) Response field: Response Text, Document (Text), url sample, Response code, Response information, Response Header, ignore status
Response text: Server response text. This is selected for common http responses.
Document (Text): Apache Tika supports server responses, including Text responses, PDF, Office, Audio, and Video formats. Jmeter uses Apache Tika to parse server response content, which consumes a lot of memory and is easy to parse and fail. Therefore, do not select this option for common http requests.
Url sample: asserted the url of the sample. If the request is not redirected (302), this is the request url. If there is a redirection (and follow the redirection), the url contains the request url and the redirection url.
Response Code: http response code, such as 101,200,302,404,501. But when we want to verify http response code such as 404,501, we need to check "ignore status ". When the http response code is 400,500, jmeter fails to send this request by default.
Response Information: The response information corresponding to the http response code, such as OK and Found.
HTTP/1.1 200 OK
HTTP/1.1 302 Found
Response Header: Response Header information, such
Server: Tengine
Date: Thu, 12 Mar 2015 09:43:52 GMT
Content-Type: text/html
Content-Length: 260
Connection: close
Location: http://www.111cn.net
(3) pattern matching rules
Including: the returned results include the content you specified and support regular expression matching.
For example:
Response field: response text
Pattern matching rule: Match
Assertions: 1, invalid 2, [a-z] +
When the returned value is {"msg": "channel invalid."}, both assertions are OK and true is returned.
Matching:
(1) equals. When the return value is fixed, the assertion can be returned, and the effect is the same as that of equals.
(2) regular expression matching. Match the returned results with a regular expression, but all the results must be matched. That is, the regular expression must be able to match the entire returned value, rather than a part of the returned value.
For example:
Response field: response text
Pattern matching rule: Match
Assertions: 1, {"msg": "channel invalid. "} 2, \ {" msg ":" [a-z] + invalid \. "\}, 3, [a-z] +
When the returned value is {"msg": "channel invalid."}, assertion 1 2 is OK and assertion 3 is false
When the returned value is {"msg": "channel invalid."}, assertion 1 3 is false, and assertion 2 is OK.
The reason is that assertion 1 can only be used for equals, while assertion 3 only matches the return value, not all.
Equals: the returned results are exactly the same as the assertions you specified.
SubString: similar to "include", it indicates that the returned results include the content you specified. However, subString does not support regular strings.
For example:
Response field: response text
Pattern matching rule: Match
Assertions: 1, invalid 2, [a-z] +
When the returned value is {"msg": "channel invalid."}, assertion 1 returns true, but assertion 2 returns false.
No: this is equivalent to reverse. If the above asserted result is true, check "no" and the final asserted result is false. If the above asserted result is false, if "no" is selected, the final asserted result is true.
IV. User experience
By gradually increasing and releasing, and setting the request to be sent permanently, you can continuously observe the CPU, memory, and bandwidth of the server and discover system bottlenecks.
When a problem is detected, you can gradually delete the code, replace the framework, and observe the Average and Error values in the aggregate report to determine the problem points and design targeted optimization solutions.
