By Dmitri Tikhanski
This post will cover the use of the JMeter Synchronizing Timer. First, let’s define when you’d like to use the JMeter Synchronizing Timer.
A high-level overview of performance test development process looks as follows:
Record or develop a single use case or end-to-end scenario
Parametrize it as required and perform correlation
Add and configure necessary elements to deal with cookies, cache, headers, etc.
Define and implement the load scenario
Regarding point 4, defining and implementing the load scenario, the most commonly used practices are:
Use the Ramp-up period property of Thread Group to simulate an increasing load
Use a Constant Throughput Timer to ensure that generated load matches exactly the required rate (X requests per second)
But what if you need to fire X requests at the exact same moment? JMeter provides a special component for this: the Synchronizing Timer. It has only one parameter: “Number of Simultaneous Users to Group by”. The timer will pause threads paused threads number will be less than the parameter specified. [RF1]
There are a few things to consider:
If the “Number of Simultaneous Users to Group by” is set to zero, the current Thread Group “Number of Threads” will be used.
If the “Group by” number is less than “Number of Threads”, i.e. there are 50 threads defined in the Thread Group and the “Group by” value is 25, two bulk releases with 25 threads each will occur.
Avoid setting a “Group by” value that greater than “Number of Threads” as the Timer will NEVER fire off and your test will be hanging forever.
Here’s a demonstration:
In this example we’ll be firing off 25 threads without the Synchronizing Timer. Then we will do the same but with an enabled Synchronizing Timer.
Exhibit A, The Synchronizing Timer is Disabled
The“Thread Name” column demonstrates that threads are starting one by one, i.e. 1, 2, 3, … 25.
The “Start Time” column shows that the first thread was started at 17:22:44.639 and the last one at 17:22:45.606. There is a difference of about one second between the first thread and the last one.
Now let’s try the same scenario but with the Synchronizing Timer enabled
Exhibit B, The Synchronizing Timer is Enabled
In this example the “Thread Name” column shows that threads started in a random order. The “Start Time” column shows that all 25 requests were released at the same moment in time.
So now you are aware of 3 techniques which can help you to implement your load scenario as close as possible to your test requirements. Not enough? It’s always possible to do some more:
JMeter Plugins offer three more elements to provide additional flexibility:
Throughput Shaping Timer
Ultimate Thread Group
Stepping Thread Group
Blazemeter offers Real Time JMeter Properties Control to change test parameters on-the-fly while the test is running
And of course Blazemeter supports all the plugins that the JMeter Plugins site offer as well as your custom extensions, scripts and configurations.