Part 1: Setting the waiting time between requests
First clarify some concepts:
1) The timer is executed before each sampler (sampler), not after;
yes, you read it right, no matter the position of the timer is placed after the sampler or below, it are executed before sampler.
2) Timers are scoped; before executing a sampler, all timers in the current scope will be executed;
3) If you want the timer to apply to only one of the samplers, add the timer as a child node ;
4) If you want to wait after the sampler is executed, you can use Test Action;
1. Constant Timer
is undoubtedly the most important timer.
It should be noted that the delay of the fixed timer does not count into the response time of a single sampler, but counts into the transaction controller's time .
As shown in the figure below, the duration of the fixed timer is set to 300 milliseconds.
The timer duration is not counted in the response time of the java request, but is counted in the total time of the "transaction controller".
If you insist on seeing this and remember the concepts of think time and pacing of loadrunner, we There is an answer:
for the "java request" sampler, the timer is equivalent to pacing in loadrunner; for "transaction controller", the timer is equivalent to think time in loadrunner.
The response time we usually say should be for a specific sampler (http request) in most cases, not for a transaction combined with a group of samplers
When the Constant Timer is placed between two http requests, the meaning it represents is: after the previous request is sent to the completion, start the time specified by the Constant Timer, and finally send the second request. It does not represent two requests. The interval between sending . Please see the picture:
In the above figure, the first request is sent at 19.701, and the reception is completed after 1.36s, and then waits for 1s of the Constant Timer, and then starts the second request.
2. The Gaussian Random Timer is
basically the same as above, except that the delay time of the timer is normally distributed within the specified range.
3. The Uniform Random Timer is
the same as above, the delay time is within the specified range, and the probability of taking a value at each time is the same.
Fourth, the constant throughput timer (Constant Throughput Timer)
allows JMeter to execute at a specified number of throughput (that is, specify TPS, but here requires specifying the number of executions per minute, not per second). The scope of the throughput calculation can be specified as the current thread, the current thread group, and all thread groups, and the basis for calculating the throughput can be the execution delay of the latest thread.
I believe that this kind of timer is still very useful in specific scenarios.
5. Synchronizing Timer At the timer ,
the thread waits until the specified number of threads is reached, and then they are released together. Can create a lot of stress in an instant.
Yes, it does the same thing as loadrunner's rendezvous point.
6. BeanShell Timer (BeanShell Timer)
This timer is usually not used. But actually, it's the most powerful because you can program yourself to do whatever you want.
When you have complex needs, you have to rely on it. For example, you want to wait after each thread has finished executing, or you want to wait when a variable reaches a specified value.
Part 2: Time setting between threads ( this Test Action, I don't know why there is no such timer in my jmeter, anyone who knows can tell me )
During continuous stress testing, when the thread completes all actions and performs the second operation, a certain waiting time needs to be set, and it can be placed after all requests, as follows: