Dmitri Tikhanski is a Contributing Writer to the BlazeMeter blog.

Become a JMeter and Continuous Testing Pro

Start Learning

Test Your Website Performance NOW! |

arrowPlease enter a URL with http(s)

Using the JMeter Synchronizing Timer

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:


  1. Record or develop a single use case or end-to-end scenario
  2. Parametrize it as required and perform correlation
  3. Add and configure necessary elements to deal with cookies, cache, headers, etc.
  4. 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:


  1. If the “Number of Simultaneous Users to Group by” is set to zero, the current Thread Group “Number of Threads” will be used.
  2. 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.
  3. 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.


arrowPlease enter a URL with http(s)

You might also find these useful:

Interested in writing for our Blog?Send us a pitch!