Different Types of Thread Groups in JMeter

  • When talking about performance testing, a very important factor is to try to simulate the actual user behavior as best possible.
  • A group of virtual users is represented in the JMeter application by a Thread Group.
  • A thread group is the base element (parent) needed in every test plan.
  • It is actually an assembly of threads executing the same scenario.
  • There are multiple thread groups available which we configure in various ways in order to accurately simulate how users interact with an application, how the load is maintained, and over what periods of time.
  • These settings derive from what the application clients require from the load tests, data from analytics, and common sense testing stuff.
  • The latest JMeter updates and plugins came with a few brand new thread groups.
  • All types of thread groups have a common option which is the Action to be taken after a Sampler error which is pretty much self-explanatory.
  • It can be to continue the thread, start the next iteration, stop the current thread, stop the entire test, or force stop the test and all ongoing threads.
  • Let’s explore each type of thread group along with their specific configuration options and try to figure out when it’s best to use each of them.

Thread Group in JMeter

Thread Group (The Classic) in JMeter

This is the most basic thread group and it has some standard settings, it can be adapted to fit most load test scenarios.

Thread group capabilities and configuration options :

  • The number of threads : Represents the total number of virtual users performing your test script per execution.
  • The ramp-up period : Is the timeframe needed for all virtual users to start running their scripts,
    Example : If you have 30 users with a ramp-up period of 30 seconds, each second, a new virtual user will start performing its user flow represented by the created script.
  • The loop count : Is the number of executions for your script.
    Example : If the loop count is set to 1 and you have set 20 threads, then the script will run 20 times with the thread start execution delay defined by the ramp-up period.
    If the loop count is set to Forever then new threads will keep starting until the tests are stopped. The condition for this scenario is that you will have a maximum of active threads equal to the value set at the Number of threads.
  • Delay Thread creation until needed : If this option is checked, the ramp-up delay and startup delay are performed before the thread data is created. If not, all the data required for all threads is created before starting the actual execution at the beginning of the test.
  • The scheduler : you can set a predefined start and end time for your tests but also a custom duration, for situations where you would like to hit the server with a constant load for n minutes. Note that the duration option overwrites the start and end times.

Likely scenarios to be used for :

  • Simple scenarios (load testing) : Where you set a predefined number of users and a ramp-up period and you start running your script n times.
  • Stress testing scenarios : Determine the upper limit of the number of concurrent users for your app before it starts to fail.
  • Soak testing scenarios : where you can set an expected load for your tests and maintain that load for a predefined period of time.

How to Use JMeter for Performance Testing

Arrivals Thread Group in JMeter

  • This is an open-source custom plugin implemented by Blazemeter.

Thread group capabilities and configuration options :

  • The time unit : This is self-explanatory and can be set to minutes or seconds.
  • The target rate : Where you define the number of new arrivals per time unit.
  • The ramp-up time : From what I have tested, this element is not 100 % accurate since the preview graph doesn’t display the exact number of total arrivals.
    This happens when the ramp-up line from the preview graph is oblique (not in steps).
    The Ramp-up step count is correlated to the ramp-up time and since the previous element is set to 0, this one won’t matter. It refers to the granularity of the arrivals increase rate => more steps = more smooth patterns. Also, if there’s a really high number of steps then the arrival rate will also display small deviations from what the preview graph displays.
  • The hold target rate : The duration which you want to run your tests for (how much time you want to keep adding new users each minute).
  • Thread iteration limit : Represents the number of loops. I haven’t figured out a use case for this particular feature so I usually just leave it blank which means it’s set to infinite until the time limit is reached.
  • Concurrency limit : Even if you set 20 new arrivals every minute, if a thread execution lasts 2 minutes, then by the end of the second minute, your app will have 40 active threads. This option helps you limit that number and you don’t have to bother implementing extra scripts to do so.

Likely scenarios to be used for :

  • Soak testing scenarios : Where you can set an expected load for your tests and maintain that load for a predefined period of time. You can do this by setting a concurrency limit thus making sure that the number of active threads won’t exceed that.
  • Conditioned scenarios where the client might say : The goal is to see how the app behaves if 50 new users access it every minute.
    This could be included in a scalability testing scenario provided that the execution time for a thread is more than 1 minute.
    If a thread’s execution time is longer than 1 minute, or the requests will progressively take longer to respond, then the number of concurrent users will gradually increase thus resulting in a form of scalability testing. For an even more controlled environment for scalability testing we will look at the next thread group:

HTTP Cookie Manager in JMeter

Free Form Arrivals Thread Group

This is basically exactly the same as the Arrivals thread group minus the less used elements like the ramp-up time and ramp-up steps count.

Thread group capabilities and configuration options :

  • The Time Unit : This is self-explanatory and can be set to minutes or seconds.
  • The Start and End values : These two should have the same value in my opinion and are the equivalent of the target rate from the Concurrency Thread Group.
    If start value equals end value and they are let’s say 20, and you set a duration of 2 minutes this means that each minute, you get 20 new arrivals with a constant ramp-up of 3 seconds between threads.
    If the start and end times are different, I haven’t figured out exactly how the ramping up is done but in any case, it’s not too uniform.

The Duration : This is equivalent to the hold target rate from the previous thread group.

The Concurrency limit : The same as for the Arrivals Thread Group.

The Threads schedule table : Where you can add multiple rows each of them being executed sequentially after the duration of the previous row has expired.

Start Value End Value Duration
10 10 2
20 20 1
10 10 1

In the above example, the new arrivals execution will be as following :

  • Minute 1 : We will have 10 new arrivals (one new arrival every 6 seconds)
  • Minute 2 : Another 10 new arrivals (one arrival every 6 seconds). This is because the Duration for the first row is set to 2 minutes.
  • Minute 3 : 20 new arrivals (one every 3 seconds)
  • Minute 4 : 10 new arrivals (one every 6 seconds)
  • This means that if you only have one row in the Threads schedule section, this thread group behaves exactly as the Arrivals Thread Group.

Assertions in JMeter

Currency Thread Group in JMeter

If your goal is to have control over the number of concurrent users in your app over a period of time, then this is the perfect type of thread group to help you do so.

Thread group capabilities and configuration options :

  • The time unit : This is self-explanatory and can be set to minutes or seconds.
  • The target concurrency : The number of concurrent users which should be maintained after the ramp-up.
  • The ramp-up time : The timeframe needed for all virtual users defined in the Target concurrency field to start running their scripts.
  • The ramp-up steps count: The granularity for starting all the threads needed to reach the target concurrency. Setting this field to 0 means that the ramp-up will be smooth, and threads will have a uniform delay between them.
    The same result is obtained if this value is really high. A lower number of steps will result in a more Rough ramp up the pattern, where the delay between threads is not too uniform.
  • The hold rate time : The duration to maintain the target concurrency before starting to gradually shut down all threads.

Likely scenarios to be used for :

  • Soak testing scenarios: Where you can set an expected load for your tests and maintain that load for a predefined period of time.
  • Note that everything this thread group does can also be done using the basic Thread Group if you set a constant number of threads, set the loop count to forever, and schedule duration.

So why use the Concurrency thread group then you may wonder?

  • It is much easier to configure all these settings with this new thread group.
  • Unlike the basic thread group, this one doesn’t create all threads upfront, it creates them only when needed meaning that extra memory will be saved.
  • Unlike using the simple thread group, the Concurrency Thread Group gracefully shuts down all threads, while the Thread Group kills them when the End Time ticks, there is no ramp-down.
  • You get a preview of what your concurrency over time will look like just by changing the initial settings.
  • This preview is accurate but it does not include the ramp-down of the virtual users since the threads are not killed and the execution duration of the scripts is different for each test and test run.

Logical Controllers in JMeter

Stepping Thread Group in JMeter

  • This is an older version of the Concurrency Thread Group and requires a bit more configuration.
  • Basically the end result is the same, the only thing which is changed is that the way the ramp-up and ramp-down are done differently.
  • The fields are pretty self-explanatory and filling the input fields is like completing an incomplete sentence: This group will start xx threads (the aimed concurrency)
  • First, wait for xx seconds, then start xx threads, next add xx threads every xx seconds using an xx second ramp-up.
  • Then hold the load for xx seconds (the hold rate time equivalent).
  • Finally, stop xx threads every xx seconds.
  • In any case, for scenarios where you have to maintain a certain number of concurrent users over a period of time.
  • I suggest using the Concurrency Thread Group since you don’t have to bother with many configurations.

Timers in JMeter

Ultimate Thread Group in JMeter

  • The ultimate thread group is highly customizable and unlike the arrivals, or free form and concurrency thread groups.
  • This one kills the active threads after the set time has expired.
  • This would translate into real-user behavior as the users just closing the application tab or browser.
  • This also means that the preview graph showing the expected parallel users will be really accurate since the ramp-down is controlled by the thread group not determined by the execution time of each thread.
  • The thread group also fires up a new thread to maintain the thread count in the situation where one thread has finished executing.

The Capabilities and configuration Options of Thread Groups :

  • The threads schedule table : Where you can add multiple rows each of them being executed sequentially each of them being started according to the Initial Delay setting.
    This means that the rows (virtual users groups) will be executed in parallel if the Initial Delay setting is the same for all fields.
  • The Start threads count field : Where you set the target thread concurrency.
  • The Initial delay : Here you set how much time you wait before starting to execute the threads from that specific row.
  • The startup time : Represents the ramp up time for all the threads set in the thread count. For example, for 20 threads and a start time of 20 seconds, you would have 1 new thread firing up every 1 second.
  • The hold load for the field : This is where you set the duration to maintain the defined number of concurrent users and is totally independent of the ramp-up time.
  • The shutdown time : The time interval for killing all the active threads.

You can add multiple rows containing these settings thus resulting in complex patterns that can simulate a fluctuating number of users hitting your servers.

Likely scenarios to be used for:

  • Complex Spike Testing Scenarios : Where you can suddenly increase the number of users per minute, then decrease it again and see how the application behaves. Using this technique you can also test the recoverability of a certain system.
Comment / Suggestion Section
Point our Mistakes and Post Your Suggestions