Using the JMeter SetUp Thread Group

The JMeter Thread Group is an essential feature. But do you know how to use it? Find out in this blog, with an extra focus on the setUP thread group in JMeter.

What Is the JMeter Thread Group?

The JMeter thread group is a feature that allows you to tailor your tests and test plans. You can use the JMeter thread group with different types of thread groups, too — not jus the regular ones! 

How to Setup the JMeter Thread Group

The setUp Thread group is used when you need to run initial actions to prepare the testing environment, prior to starting your main test. These actions should be configured within the SetUp Thread Group and not within the regular Thread Group that you will use for running your performance test.

When to Prepare the Test Environment

Preparing the target environment for a load test is required in many testing situations. For example, when you need to:

• Create a list of registered users in the database
• Retrieve required data from a database and use it during the load test
• Populate the database with test data before the load test starts
• Run pre-load test calculations that should be executed separately from the load test. For example, calculating some parameters once and then using them during the load test

Prepare the setUp Thread Group

The setUp Thread Group

JMeter enables its users to run pre-load test actions via a special thread group – setUp Thread Group.

As mentioned above, the setUp Thread Group is a special type of Thread Group that can be handy if you need to perform pre-test actions. With the setUp Thread Group, you can set-up your testing environment before running the load test thread group. The "inverse" of this action is the TearDown Thread Group, which is used for post-test actions after all the other thread groups are done (deleting users from the database for example).

As we can see above, the setUp Thread Group and the regular Thread Group are almost identical in terms of configuration options. The only difference is that the setUp Thread Group will execute before the execution of the other thread groups.

Now, let’s see it in action.

Create Your Script

Let’s define the following scenario: We want to test 10 users that will login to our website and purchase some clothes. We will need to create the users before executing the test. This can be done using the setUp Thread Group in the following way:

Configure the Database

I’ve created a database collection called “app-sign-ups” (I used a free trial of restdb.io). It is configured with 3 fields: “first-name”, last-name” and “email”. Currently, the collection has no entries.

Configuring our script:

First, create a test-plan that contains the setUp Thread Group.

The setUp Thread Group consists of a CSV Data Set Config with a reference to the CSV file containing the list of users to register (first name, last name and email address)

In our example, we send the registration request with 3 variables: “firstName”, “lastName” and “emailAddress”. JMeter will parse the CSV file and populate those variables with the values in correspondence to the data of the CSV file.

Here is a screenshot of our CSV file that contains the details of 10 users:

Now let’s configure the registration request with a POST method that will initiate an API call to add a new record to our collection (registering a user). We will use the following API call:

POST https://sampledb-d52b.restdb.io/rest/app-sign-ups (data no longer supported)

And the Data that will send in the Body of the request:

{
"first-name":"${firstName}",
"last-name":"${lastName}",
"email":"${emailAddress}"
}

We need to make sure that we are using the same variable names we defined in our CSV and the same fields we defined in our database.

I’ve also added an HTTP Header Manager which specifies the content-type as “application/json” and the API key with the value of our database API key.

Next, add the regular Thread Group which contains the actual test logic and samplers:

1. Login
2. Purchase
3. Checkout
4. Logout

Once we run this script, the first thread group to run will be the setUp Thread Group. It will create 10 users since we configured 10 threads with 1 iteration. Once the setUp Thread Group is finished, the other thread group will start executing, which will be the start of our load test.

In the following screenshot, we can see the results of our run; The requests sent to our database were successful and we received a 200 response code. Notice that the setUp Thread Group will be executed first, no matter the order that it appears in the GUI.

The JSON response indicates that the request was successful:

Let’s go back to the database and verify that it has been modified as expected with the creation of 10 new users.
We can see that the entries are now populated by the values within our CSV file.

That’s it! Now that our testing environment is ready, we can move forward and check the behavior of our load test.

SetUp Thread Group when you want to run your script with more than one engine

When integrating our test scenario with BlazeMeter, you can increase the number of engines running the test.

Under the Load Distribution configuration, you have the ability to choose how many engines to allocate to run your test and how the concurrency is spread over these engines.

The simple default configuration is to set BlazeMeter to run with 1 engine.

But what will happen if we want to configure more than 1 engine?

Each engine will take part in generating the actual load and simulate the number of threads/virtual users specified in the script you provide.

As you can see from the screenshot below, each engine will perform the script, so we end up with setting the environment multiple times.

To overcome this problem of each engine running the setUp Thread Group logic, we can make use of the following variable:

${__env(TAURUS_SESSIONS_INDEX)}

TAURUS_SESSIONS_INDEX is evaluated in correspondence to the number of engines you chose to run with. For example, if you choose to run with 2 engines then TAURUS_SESSIONS_INDEX will be evaluated to 1 (for the first engine) and 2 (for the second engine).

We need to configure BlazeMeter to run the logic under the setUp Thread Group only once.

To achieve this, we will modify our JMX script as follows:

Add an “If Controller” before as a parent to the registration sampler. Set the condition to the following:
${__groovy(${__env(TAURUS_SESSIONS_INDEX)} == 1)}

Here is the configuration in JMeter:

When running a performance script with a large number of threads, it is generally recommended to use “Interpret Condition as Variable Expression” with “groovy” over the default JavaScript interpretation as the former consumes more resources.

What will happen is that engine #1 will set up the environment while engine#2 will skip the “if” statement inside the setUp Thread Group and continue straight to the regular Thread Group. Below are the results of the test run that are shown as part of the Request Statistics report:

One thing to note is that engine#2 will start executing the regular Thread Group before engine#1 has finished the set-up process.

You should configure all the engines to wait until the set-up process is complete.
One way is to add a timer inside the setUp Thread Group with the amount of time we know it should take to set-up the environment. We have decided to add a Constant Timer (see screenshot above).

Bottom Line

In this blog post, I’ve covered how we can utilize the setUp Thread Group in JMeter and run it with multiple engines through BlazeMeter.

BlazeMeter is the ideal testing platform for JMeter testing at scale since it adds on to JMeter. With BlazeMeter, JMeter users can enjoy additional benefits that add scalability, security, and enterprise capabilities when load testing in the cloud. BlazeMeter also contributes to the JMeter open source community, through JMeter plugins, documentation, and fixes. 

Explore how to leverage other key JMeter features with BlazeMeter. Try BlazeMeter for free today. 

START TESTING NOW

Related Resources

• JMeter Regular Expression Extractor: How to Extract Tokens and Session IDs to Variables