JMeter parameter settings

Reference Link: http://www.knowsky.com/367353.html

JMeter is a popular open source tool for load testing with many useful functional components such as thread group, timer, and HTTP sampling (sampler) components. This article complements the JMeter User manual and provides guidance on developing quality test scripts for some analog components using JMeter.

At the same time, this paper also discusses an important content: How to verify the test results after the precise response time requirement is specified, and how to operate if the confidence interval is used to analyze this strict statistical method. Please note that I assume that the readers of this article understand the basics of jmeter, and the examples in this article are based on Jmeter2. 0. Version 3.

Determine the ramp-up period (determine) of a thread group

The first feature of the JMeter script is the thread group, so let's take a look at it first. As shown in the first example, the thread group needs to set the following parameters:
• Number of threads.
ramp-up period.
• The number of times the test was run.
• Start time: Immediate or scheduled time, if the latter, the thread group contains elements to specify the starting and ending time.

Figure 1. JMeter Thread Group (JMeter)

Each thread runs the test plan independently. Therefore, thread groups are commonly used to simulate concurrent user access. If the client does not have sufficient capacity to simulate heavier loads, the JMeter distributed test function can be used to remotely control multiple JMeter engines through a jmeter console to complete the test.

The parameter ramp-up period is used to tell JMeter how long to build all the threads. The default value is 0. If ramp-up period is not specified, that is, ramp-up period is zero, JMeter will immediately establish all threads, assuming ramp-up period is set to T-second, all threads are set to N, and JMeter will establish a thread every t/n second.

Most of the parameters of a thread group are self-explanatory, and only ramp-up period is difficult to understand because it is not easy to set the appropriate values. First, if you want to use a large number of threads, ramp-up period generally do not set to 0. Because if set to 0, JMeter will set up all threads at the beginning of the test and immediately send access requests, so it is easy to saturate the server, and more importantly, to increase the load implicitly, which means that the server will be overloaded, Not because of the high average access rate but because of the unusual initial access spikes caused by the first concurrent access of all threads, this behavior can be seen through the JMeter aggregation reporting listener.
This exception is not what we need, so the rule of determining a reasonable ramp-up period is to get the initial clickthrough rate close to the average Ctr. Of course, you might need to run some tests to determine the reasonable amount of traffic.

For the same reason, an oversized ramp-up period is also inappropriate because it will reduce the load on peak access, in other words, some of the initial startup threads may have ended when some threads have not started.

So, how to test ramp-up period I too small or too big? First, speculate on the average click-through rate and the bus path in addition to the CTR to calculate the initial ramp-up period. For example, assuming that the number of threads is 100 and the estimated CTR is 10 times per second, the estimated ideal ramp-up period is 100/10 = 10 seconds. So, how to put forward a reasonable estimate Ctr? There is no good way to get it by running a test script once.

Second, in the test plan, add an aggregated report listener, 2, which contains the average click-through rate for all individual access requests (one samplers). The clickthrough rate for the first sampling, such as an HTTP request, is closely related to ramp-up period and the number of threads. By adjusting the ramp-up period, the foundation rate of the first sample is close to the average sampling.

Click to view larger image

Figure 2 JMeter Aggregation Report

Third, check the JMeter log (file location: Jmeter_home_directory/bin) When the last thread started, whether the first thread really ended, the time difference between the two is normal.

In summary, the ability to determine an appropriate ramp-up time depends on the following two rules:
• If the click rate of the first sampler is close to the average of other samplers, can it be avoided that the ramp-up period is too small.
• When the last thread is started, whether the first thread is really over, it is best to take as long a time as possible to avoid ramp-up period too large.

In some cases, the conclusions of these two rules will conflict with one another. This means that it is not possible to find a suitable ramp-up period that satisfies two rules at the same time. Bad test plans often lead to these problems, because in such a test plan, the sampler will not be able to fully capture the data, possibly because the test plan execution time is too short and the thread will run quickly.



user think times (think time), timers, and proxies (proxy server)

An important element to consider in a load test is the think time (think time), which is the pause between two successful access requests. There are a number of situations where volatility causes delays: Users need time to read text, fill out forms, or find the right links. Failure to think seriously about time can often lead to distortion of test results. For example, the estimated value is inappropriate, that is, the maximum number of users the system can support (concurrent users) seems to be less.

JMeter provides a complete set of timers to simulate think times (think time), but there is still a problem: how do you determine the appropriate time to think? Fortunately, JMeter provides a good answer: Use the JMeter HTTP Proxy server component.

The proxy server logs actions when browsing a web app using a common browser, such as Firefox or Internet Explorer. In addition, JMeter will establish a test plan while recording the operation. This feature provides the following conveniences:

• Do not have to manually establish HTTP access requests, especially if you want to set some boring parameters (however, non-English parameters may not work correctly). JMeter will record everything including the hidden field (hidden fields).

• In the generated test plan, JMeter will contain all the HTTP headers generated by the browser, such as User-agent (E. G. , MOZILLA/4. 0), or Acceptlanguage (E. G. , Zh-tw,en-us;q=0. 7,zh-cn;q=0. 3) and so on.

· The JMeter will set up some timers based on the recording operation, and the delay time is set exactly according to the actual operation.
Now let's look at how to configure the JMeter recording feature. On the JMeter console, right-click on the Workbench (WorkBench) component and select Add the HTTP Proxy Server.  It is important to right-click on the workbench instead of on the test plan, because now is the time to configure the logging operation instead of running the test plans. HTTP Proxy Server is implemented by configuring the browser's proxy server so that all access requests are sent through JMeter (, thus being jmeter to record the access process).

As shown in 3, some parameters of the HTTP proxy server (HTTP proxy) component must be configured:

• Port: The listening port of the proxy server

• Target controller: Is the controller that the agent uses to store the generated data, by default, JMeter will find a record controller for storage in the current test plan, and can also choose to store any control in the drop-down menu. Usually the default value is available.

• Grouping (Grouping): Determines how the generated components are grouped in a test plan. With multiple options, you can typically choose to store only the first swatch of each group, otherwise the URLs will be recorded as-is, including pages containing images and javascripts scripts. Of course, you can also try the default "No Sample Grouping" ("Do not group samples"), look at the original test plan established by JMeter.

• Include mode (Patterns to include) and exclusion mode (Patterns to Exclude): Helps filter some unwanted access requests.

JMeter parameter settings