In the process of work recently, many friends asked me how to set up concurrency in JMeter thread group. I found that many friends were not very clear about many parameters in the thread group, so I wrote an article today to popularize the relevant information in the JMeter thread group. , and also make a simple analysis of which concurrency strategy to use in which scenario.
1. What is a thread group
1. Definition
A thread is equivalent to a virtual user. As the name implies, a thread group is a collection of multiple threads. It is a user pool for executing specific test cases. It is the starting point of any test plan. It can make all components in this thread group follow the set The test cases are executed, so the components to perform performance tests must be under a certain thread group, otherwise it cannot be controlled.
In the GUI page of the thread group, we can simulate the number of user threads, the time required to start all threads, the number of times to execute the test, and also use the scheduler to execute the cycle length of the test, timing execution, etc.
2. Add thread group
Test plan - right click - add - thread (user) - thread group
3. Explanation of each parameter in the thread group
Name: Thread group name, custom, no requirement, default is also acceptable, if there are multiple thread groups, it is recommended to be recognizable and related to the business
Note: Explain the thread group, customize the content, and it can also be empty
action to perform after a sampler error
- Continue: continue running when the request fails
In our regular stress testing, there are usually a large number of concurrent threads, and it is normal for individual requests to experience abnormal responses , as long as the error rate is not particularly high. In addition, abnormal responses may be recorded due to performance problems, which can also be used as a reference for us to check whether the service has performance problems or stability.
- Start the next process cycle: When a request fails, the remaining requests in the same script will not be executed, but will be restarted.
- Stop thread: When there is an error in the request, stop the current thread and stop executing it. If we run 10 threads, and one of the threads has a request error, the thread will be stopped, and only 9 threads will be concurrent. If there are more errors, the more threads will stop , and the execution time will be longer. Because there are fewer running threads, the load pressure on the server will drop, resulting in no reference for the pressure test results.
- Stop test: stop all threads when there is a request error, but no matter which request the thread executes, it will stop after executing all the requests in the thread group of the current loop
- Immediately stop the test: When a request fails, stop the entire test scenario immediately.
thread properties
- Number of threads: the number of simulated users, one thread is one user
- Ramp-Up time (seconds): the time required to start all threads, in seconds, for example, if 100 threads are to be started within 1 second, the interval between each thread startup is 10ms
- Number of loops (forever): The number of times the request is repeated. If you check forever, you cannot fill in the number of times and it will be executed all the time; if you don't check forever, entering a number in the input box means requesting to repeat the corresponding number of times.
- Delay thread creation until needed: check to start threads and run according to Ramp-Up time; uncheck to start all threads first, and then start requests according to Ramp-Up time
- Scheduler: set start running time
- Duration (seconds): How long to execute, in seconds, if it must be executed for 5 minutes, fill in 300
- Startup delay (seconds): the thread will not run after the execution button is clicked, and the thread will start running after the delay time has elapsed
Two, setUp and tearDown thread group
When we need preconditions or preset values for stress testing, we will use the setUp thread group; when we need to do some cleaning or post-test work after the stress test is executed, we will use the tearDown thread group.
1. setUp thread group
The setUp thread group is used to perform pre-test operations, and its configuration items are exactly the same as the normal thread group, except that the setUp thread is executed before the normal thread group is executed. Usually used for initialization before running test tasks. For example, establishing a database connection initialization work
2. tearDown thread group
The tearDown thread group is used to perform post-test operations. Its configuration items are exactly the same as the normal thread group. The difference is that the tearDown thread group is executed after the normal thread group is executed.
3. Application of thread groups in test scenarios
In JMeter, our stress test scene setting is done in the thread group. In the thread group, we need to combine various operations of the user. Especially in complex scenes, we need to cooperate with multiple controllers to set the scene. Today here Let's not talk about complex scenarios first, let's talk about how to complete the settings in JMeter for our commonly used scenarios.
The following two scenarios roughly explain the use of different pressure measurement strategies in different scenarios
1. Scene 1
Pressure test target: shopping scenario [login-select product-add to shopping cart-pay], the performance target of this scenario is that the response time should not exceed 1s, and the TPS of each interface should reach more than 50.
Analysis: For this type of scenario, we generally recommend that you choose to execute this performance scenario by time during stress testing. The execution can refer to the following. The specific number of threads, Ramp-Up time, and duration can be adjusted according to the actual situation
| Threads |
Ramp-Up time |
Cycles |
scheduler |
duration |
| 1 |
1 |
forever |
√ |
300s |
| 50 |
1 |
forever |
√ |
300s |
| 100 |
1 |
forever |
√ |
300s |
| ...... |
1 |
forever |
√ |
300s |
2. Scene 2
Pressure test target: On average, about 20 users will perform the export operation every day, and the number of exports can be up to 60 times. It is hoped that the export response time will not exceed 3 seconds
Analysis: For this type of scenario, it is recommended to choose to perform the performance scenario stress test according to the number of cycles
| Threads |
Ramp-Up time |
Cycles |
scheduler |
duration |
| 1 |
1 |
60 |
× |
× |
| 10 |
1 |
6 |
× |
× |
| 20 |
1 |
3 |
× |
× |
| 30 |
1 |
2 |
× |
× |
Through the above two scenarios, we can probably see that the number of cycles can be used when the number of times or the request volume is low. However, most scenarios use more time-based cycles. This scenario setting is not absolute. , needs to be considered comprehensively based on business scenarios, user habits, and script request related settings. The above two scenarios are used to guide readers to better understand the use of different stress testing strategies in different scenarios, and are not recommended as stress testing strategies, but are for reference only.
Four. Summary
I briefly talked about the definition of the thread group and the description of related parameters, and gave a case study on how the thread group is applied in the test scenario. I believe that the friends have a clear understanding of the thread group after reading this. Can help you in your performance testing work!