jmeter timer usage

1) The timer is executed before each sampler (sampler), not after;
yes, you read that right, no matter the position of the timer is placed after the sampler or below, it is obtained before the sampler implement.
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 duration of the timer is not counted in the response time of the java request, but 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 group of sampler combination transactions
2. Gaussian Random Timer is
basically the same as above, just a timer The delay times are normally distributed within the specified range.
3. 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 this 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.