Blog
July 8, 2020
JMeter Timer Overview
The purpose of all “Timer” test elements is pausing a JMeter Thread representing a virtual user for a certain amount of time. The main goal of using timers is simulating a virtual user’s “think time”. In the world of load testing, “think time” stands for simulating real user behavior which causes people to wait between interactions with a web application.
A high-level overview of how JMeter works looks as follows:
- When a Test Plan is started, JMeter kicks off a thread per virtual user
- Each thread starts executing samplers upside down (or according to the Logic Controllers, if any) as fast as it can
- When no samplers are left to execute and no loops to iterate the thread is being shut down
So far so good, but the highlighted bit has nothing in common with reality in this case. Real-life users don’t hammer a web application non-stop; they need some time to consume the returned content, plus some time to “think” about their next action and this “think time” needs to be accurately simulated as well. It’s important to remember that the whole idea of the load test is simulating real user’s behavior as close as possible.
Think times may vary. For example, if the user is watching images, he/she takes seconds between performing actions (requesting next image). Or, for another example, If the user replies to a forum post, it may take minutes to compose the response and the amount of requests while the user’s typing will be minimal (i.e. periodical auto-save draft) or even zero.
Assuming all of the above, 2 conclusions can be made:
- Timers need to be used.
- There is no “recipe” or recommended think time values, as think times may vary from application to application.
In this post, we’ll walk through all available timers and explain what each of them does so it would be easier for you to choose the most appropriate one.
Back to topTimers Scope and Processing
Just like JMeter Assertions, JMeter Timers also have their scope, but unlike Assertions Timers, they are executed before each sampler in their scope. If there is more than one timer in the scope, all the timers will be processed before the sampler occurs. Additionally, timer execution time is not being recorded, so if the Timer pauses the thread for 1 second and the sampler execution time is 3 seconds, 3 seconds will be recorded as the sampler execution time. If you need to record the Timer execution time as well, you need to use Transaction Controller.
Given the below figure:
- Timer A - applicable to Sampler A only
- Timer B - applicable to Sampler A and Sampler B
- Timer C - applicable to Sampler A, Sampler B and Sampler C
- The Timers are executed before the sampler’s execution
- The Timer execution time is not added to the sampler execution time
If you need to insert a delay after a sampler you can use the Test Action sampler. The Test Action sampler:
- Doesn’t generate the sample result (it won’t be present in the load reports or graphs)
- Can pause the thread for a static or random (see i.e. __Random() function) amount of time
- Can be used as a parent sampler for any JMeter Timer if your delay logic is more complex than a static or random think time
Timers Explained
As per current version of Apache JMeter (which is 5.4), there are the following Timer test elements available:
- Constant Timer
- Uniform Random Timer
- Gaussian Random Timer
- Poisson Random Timer
- Constant Throughput Timer
- Synchronizing Timer
- BeanShell Timer
- BSF Timer
- JSR223 Timer
Personally I consider the first 2 - Constant Timer and Uniform Random Timer - sufficient to cover 99% of test situations and encourage you to use them in your scripts. However if your think time simulation requirements are based on more complex mathematical and statistical distributions, you’re very welcome to get familiarized with the others.
Constant Timer
The Constant Timer can be used to pause each thread for the same “think time” between requests.
The above configuration will add a 5-second delay before the execution of each sampler, which is in the Constant Timer’s scope.
You can also use a JMeter Function or Variable in the “Thread Delay” input. In that case the timer will stop being “Constant”.
Uniform Random Timer
The Uniform Random Timer pauses the thread by a factor of:
- The next pseudorandom uniformly-distributed value in range between 0.0 (inclusive) and 1.0 (exclusive)
- Multiplied by “Random Delay Maximum”
- Plus “Constant Delay Offset”
So the default configuration is:
- 100 Random Delay Maximum
- and 0 Constant Delay Offset
It will pause affected samplers by a random number of milliseconds in range from 0 to 99 as the formula will look like |0.X * 100 + 0| where X can be a digit between 0 and 9 inclusively.
Gaussian Random Timer
A Gaussian Random Timer calculates the thread delay time using an approach like a Uniform Random Timer does, but instead of a uniformly-distributed pseudorandom value in 0.0 - 0.9 range, the normal (a.k.a. Gaussian) distribution is being used as the first argument for the formula.
There are several algorithms for generating normally distributed values, in JMeter Marsaglia polar method is used which takes the next 2 random values U and V in -1 to 1 range until the S = U2 + V2 > 1 condition is met. Once S is defined it is used in the formula
to return the next pseudorandom Gaussian (“normally”) distributed value. The first time the method is called it returns X, the second time it will return Y, the third time it starts over and will return the new X, etc.
So given the default Gaussian Random Timer configuration:
- Deviation - 100
- Constant Delay Offset - 300
The “Sleep” value will be |X (or Y) * 100 + 300| so the threads will be paused for a time frame from 1 to ~600 milliseconds.
Poisson Random Timer
A Poisson Random Timer uses the next random number from Poisson Distribution using the user-defined λ parameter which is “Lambda” (in milliseconds) plus the “Constant Delay Offset”).
If you’re interested in a Poisson random number generation, you’re welcome to read the aforementioned Wikipedia article and Generating Poisson random values by John D. Cook to get an idea on how the delay value is being calculated. In addition, as JMeter is an open-source software you can always download the source code distribution corresponding to your JMeter version (we recommend using the latest version of JMeter where possible as it contains the most recent enhancements, bug fixes, performance improvements, brand new test elements, etc. The Poisson Random Timer class source lives at http://svn.apache.org/repos/asf/jmeter/trunk/src/components/org/apache/jmeter/timers/PoissonRandomTimer.java SVN URL.
When using the default parameters (100 ms as Lambda and 300 ms as Constant Delay Offset), the Poisson Random Timer will generate a delay in range from ~375 to ~425 milliseconds.
As you can see, the Poisson Random Timer-generated random values distribution (given default JMeter values) is lower than the Uniform Random Timer and the Gaussian Random Timer.
Synchronizing Timer
A Synchronizing Timer is described in detail in our Using the JMeter Synchronizing Timer article. In short, it pauses all the threads in its scope unless their number won’t be equal or greater than the number, specified in “Number of Simulated Users to Group by” input. In the current JMeter 5.4, it is possible to set the timeout value so the test could continue even if desired number of threads to kick off is not reached.
Constant Throughput Timer
A Constant Throughput Timer can pause the threads in order that a goal-oriented scenario could be implemented. Goal-oriented scenario is a load test type where the target is not to simulate X concurrent users, but X requests per second. A Constant Throughput Timer works precisely on the “minute” level, so make sure that your test lasts long enough (1 minute or more) and you use a reasonable ramp-up time to avoid spikes (unless you’re doing some form of stress testing). How to use JMeter's Throughput Constant Timer.
Beanshell, BSF and JSR223 Timers
The last 3 timers in this article are scripting-based timers. It means that you will need to implement the thread delay logic yourself using one of supported scripting languages. Usually it is not required, however, if you need to define think times based on some unique algorithm which is not currently provided by JMeter, you can create your own implementation of the algorithm using one of these timers. Out of box JMeter supports Beanshell, JavaScript and JEXL languages. You can add relevant jars to enable support for other languages.
In short, to use a scripting-based timer you need to:
- Perform a calculation of delay using your own algorithm
- “Tell” threads to sleep for a calculated amount of time using a return statement, returning the calculated value (you can also perform “sleep” directly in the timer, however, it is not very recommended)
Which Timer/Language to Choose
It is recommended to use JSR223 test elements and Groovy as a language for any scripting as being a properly configured Groovy script being used in JSR223, Sampler can be almost as fast as Java while Beanshell and JavaScript need to be interpreted, which causes some performance overhead. See Beanshell vs JSR223 vs Java JMeter Scripting: The Performance-Off You've Been Waiting For! for explanations, instructions on how to add “groovy” scripting engine support to JMeter and Beanshell vs JSR223+groovy benchmark.
JMeter Pre-Defined Variables
Scripting-based timers provide the following predefined variables:
- vars
- props
- log
- prev
- ctx
These entities (as well as some scripting examples) are described in detail in the How to use BeanShell: JMeter's favorite built-in component guide.
Back to topConclusion
This is pretty much all on how to make your tests closer to real user behavior. If you looking for more recommendations on how to make tests look realistic from a web browser perspective, you’re welcome to read How to make JMeter behave more like a real browser.
To learn more advanced JMeter and explore hundreds of free testing-related resources, check out BlazeMeter University!