If you’re new to JMeter, one of the first concepts you’ll encounter is the Thread Group. It’s a core feature that plays a vital role in performance testing, and understanding it is the key to creating accurate and effective test plans.
So, what exactly is a Thread Group? Think of it as the foundation of your JMeter test. It’s where you set up the number of virtual users (called threads) interacting with your application, how often they will perform actions, and how long the test will run. Essentially, the Thread Group helps you simulate real-world user behavior to check how your application performs under different load levels.
Why is this important? A poorly performing website or app can lead to lost customers, bad reviews, and even financial losses. By using JMeter’s Thread Groups, you can identify performance issues before they impact your users. It helps you answer questions like:
- Can my website handle 1,000 users at once?
- Will my app slow down during peak traffic?
- Are there any hidden issues under heavy load?
In this guide, we’ll explain everything you need to know about Thread Groups in JMeter. From basic setup to advanced configurations, you’ll learn how to use them to create realistic performance tests and get reliable results.
What we will discuss –
So, let’s begin.
Adding Thread Groups To Test Plan
When you open up Jmeter and create a New Test Plan, then it looks something like this –
So, to add a Thread Group to our Test Plan, we need to
- Right-click on the Test Plan.
- And then Add > Threads (Users).
Here, we see four options –Thread Group, setUp Thread Group, tearDown Thread Group, and Open Model Thread Group.
Thread Group is one of the most important features in JMeter, and this article will focus solely on the ThreadGroup. We will write separate articles for the other types of Thread Groups.
Thread Group
As mentioned before, to add a Thread Group in Jmeter
- Right-click on the Test Plan.
- And then Add > Threads (Users) > Thread Group.
This is what the Thread Group configurations look like –
The Thread Group configuration page includes several components, but let’s focus on the Thread Properties before diving into the other settings. In most cases, these properties are the ones you’ll adjust frequently, while the other components on the page, though important, are not frequently modified.
Let’s discuss the above
1. Number of Threads (Users)
This property defines how many virtual users (or threads) will interact with your application during the test. Each thread acts as an independent user performing the same tasks, such as visiting a webpage or making an API request.
Example:
Imagine you want to simulate 50 users accessing your website simultaneously. In the Number of Threads (users) field, you would enter 50. JMeter will create 50 virtual users, each sending requests to your application simultaneously.
2. Ramp-Up Period
The ramp-up period is the time JMeter takes to start all the threads (users). Instead of launching all users at once, it gradually adds them over the specified time. This helps mimic a real-world scenario where users don’t all visit your application at the exact same moment.
Example:
Let’s say you’ve set the Number of Threads to 50 and the Ramp-Up Period to 10 seconds. JMeter will start adding users over 10 seconds, meaning it will add 5 users per second (50 users ÷ 10 seconds = 5 users/second ). By the end of 10 seconds, all 50 users will be active.
If the ramp-up period is set too low, all users will start at the same time, which could create an unrealistic load on your application.
3. Loop Count
The loop count determines how many times each thread (user) will perform the set of tasks in your test plan.
Example:
If you set the Loop Count to 2 and have 50 threads, each virtual user will repeat the test scenario twice. This means your application will handle a total of 100 interactions (50 users × 2 loops).
If you set the Loop Count to Infinite, the threads will keep running until you manually stop the test or set a duration limit ( we will discuss this later in the post ).
Putting it all together with an example
Now that we’ve covered the basic concepts of Number of Threads, Ramp-Up Period, and Loop Count, let’s apply them to create a real test plan. In this example, we’ll simulate users sending GET requests to the API endpoint https://jsonplaceholder.typicode.com/posts/1 using JMeter.
- Start with a New Test Plan
Open JMeter and create a new Test Plan. This will serve as the overall structure for your test, where you’ll define the components like Thread Groups, Samplers, and Listeners. - Add a Thread Group
Right-click on the Test Plan and choose Add > Threads (Users) > Thread Group. This is where you’ll configure the three main properties we’re focusing on. - Set the Number of Threads
In the Thread Group settings, set the Number of Threads. For this example, let’s simulate 50 virtual users interacting with the API. Enter50in the Number of Threads field. This means JMeter will create 50 users to send requests to the API. - Define the Ramp-Up Period
Now, you’ll set the Ramp-Up Period. Let’s say you want the 50 users to gradually interact with the API over 10 seconds. Enter 10 in the Ramp-Up Period field. JMeter will start with 5 users per second, so after 10 seconds, all 50 users will be active and sending requests
Example:- Number of Threads: 50
- Ramp-Up Period: 10 seconds
This setup ensures that the API is not overwhelmed by 50 requests at once, but instead, users are gradually added to simulate more natural traffic.
- Set the Loop Count
The Loop Count defines how many times each virtual user will execute the test scenario. Let’s say you want each user to send the GET request 3 times to the API. Set the Loop Count to3. This means each of the 50 users will make 3 requests, resulting in a total of 150 requests (50 users × 3 loops).
Example:- Loop Count: 3
This setup will send 150 requests to the API, helping you test how it performs with repeated traffic from multiple users.
- Loop Count: 3
- Add an HTTP Request Sampler
Note: Don’t worry. If you do not know about the HTTP Request Sampler, we will write a separate post about it. For now, just know that it is used to execute an API in JMeter.
After configuring the Thread Group, you need to define what actions the users will perform. To do this, add an HTTP Request Sampler to the Thread Group. Right-click on the Thread Group, then choose Add > Sampler > HTTP Request.In the HTTP Request sampler, set the following details:- Server Name or IP: jsonplaceholder.typicode.com
- Protocol: https
- Method: GET
- Path: /posts/1
- Add Listeners for Monitoring Results
To track and analyze the results of the test, add a Listener. Right-click on the Thread Group and choose Add > Listener > Aggregate Report.
Below is the video where we have done all of the above steps
Let’s now talk about the other Thread properties –
Let’s discuss them one by one.
Specify Thread Lifetime
When determining the loop count isn’t possible, we can utilize the “Specify Thread Lifetime” feature to address this challenge. We can configure the Loop Count to run indefinitely and specify the Duration for which the test plan should execute.
There are two inputs to be filled, if you select the “Specify Thread Lifetime” checkbox –
- Duration (seconds)
- Startup delay (seconds)
The Duration (seconds) setting defines how long the test plan will run. For example, if you set it to 10 minutes, the test plan will execute for 10 minutes.
Startup delay (seconds) is the amount of the delay before the first request executes. So, the requests won’t start executing until the delay period has passed.
For example, we set the Duration (seconds) to 20 and the Startup Delay (seconds) to 10. As demonstrated in the video below, no requests are sent during the first 10 seconds. Afterward, the test plan runs for 20 seconds, resulting in a total test plan duration of 30 seconds.
Delay Thread Creation until needed
The “Delay Thread Creation Until Needed” option in JMeter controls when threads are created during a test.
By default, JMeter creates all the threads (users) in the Thread Group at the start of the test, regardless of when they will execute their tasks. When we enable this option, threads are created only when they are ready to start executing, which can save memory and reduce resource usage in tests with high thread counts or long ramp-up periods.
But how can we observe this in action? Specifically, can we determine whether threads are created at the start or only when needed after selecting the “Delay Thread Creation Until Needed” option?
This can be better visualized using a high number of threads and a sufficiently large ramp-up period, as well as by enabling the thread lifetime specification.
We will also use the logs and “Active Threads Over Time” listener. It will help us visualize the creation of threads.
Number Of Threads – 180
Ramp-Up period – 30
Duration – 20 seconds
Startup delay – 10 seconds
Without selecting the “Delay Thread Creation Until Needed” option:
Please look at the last thread shown in the logs ( it was the 180th thread ), meaning it was started at a certain point, even if it was not needed.
Selecting the “Delay Thread Creation Until Needed” option:
Now, look at the last Thread group; it was 118th, meaning not all threads were created until they were actually needed.
Same user on each iteration
When you run a test with multiple iterations, each request from a thread (representing a user) is treated independently. This means the session is not maintained between iterations. However, in many scenarios, you may want to mimic the behavior of a single user interacting with a system multiple times without creating a new session for each request. This is where the “Same User on Each Iteration” option comes in.
When we enable “Same User on Each Iteration,” JMeter will make sure that the same user (or thread) is used for every request in a single test run. This means JMeter will remember things like the session, any data, or settings associated with that user, just like a real person browsing a website.
Now, let’s move on to discuss the remaining settings of Thread Group –
The “Action to be taken after a Sampler error“ settings determine how the test plan will proceed if an error occurs. As shown in the image above, there are five options available to choose from.
The default option selected is Continue.
So, let’s discuss a little bit about all of them.
Continue
What It Does: When a sampler error occurs, JMeter simply moves on to the next request in the current thread group. The test will continue running as if the error never happened.
When to Use It: We should use this option when you want to continue testing, even if there are errors. This is useful in situations where you want to collect results for all requests, even if some of them fail. For example, if you’re doing load testing, you may want to see how the system behaves under stress, even when errors occur.
Start Next Thread Loop
When we choose “Start Next Thread Loop,” JMeter will immediately start the next iteration of the thread, skipping any remaining requests in the current loop.
What It Does: If an error occurs during a sampler request, JMeter will skip to the next loop of the current thread. It doesn’t process any further samplers in the current iteration and starts fresh with the next iteration.
Stop Thread
The “Stop Thread” option tells JMeter to stop the current thread immediately if a sampler error occurs.
What It Does: When an error occurs in the sampler, JMeter will halt the execution of the current thread. No further requests will be sent by that thread, and the thread will be considered finished.
Stop Test
When we choose “Stop Test”, JMeter will stop the entire test execution if a sampler error occurs in any of the threads.
When to Use It: This option is helpful when you want to halt the entire test if there’s a critical error. For instance, if you’re testing an API and one error means that the entire test setup is compromised, stopping the test might be the best choice to prevent misleading results.
If there are any ongoing requests, Jmeter will wait for those requests to be completed before halting the entire test execution. We can consider it as a soft stop.
Stop Test Now
The “Stop Test Now” option is similar to “Stop Test,” but it’s more immediate and forceful.
If an error occurs, JMeter will immediately stop the test without completing the remaining samplers or threads. This is a hard stop.
This is it for Thread Groups in Jmeter. We hope that you have liked the article. If you have any doubts or concerns, please write to us in the comments or mail us at admin@codekru.com.