How to Use the Delay Thread Creation on JMeter
If you go to the Apache JMeter™ best practices page, you will find a helpful tip about the ability to delay thread creation until thread sampling begins. However, it is quite common that the JMeter documentation gives you very nice tips, but does not share a clear explanation why it is better for you to implement them, and in which cases. In this article, we will try to fill in this gap and explain to you the benefits of using this option and in each situation, when it is worth it and when it is not.
First of all, let's start with the basics. The delayed threads creation functionality was introduced in JMeter version 2.8. Previously, when you were going to spin up 1000 users during your performance tests, even if you had a ramp up time for users, JMeter allocated memory for all the threads right away. This meant that even if your last user was going to start sampling after let's say 30 minutes or even 1 hour, all the required resources were already allocated for this user when the script started. For a better explanation, let’s run the same test script in both modes: with and without having threads creation delayed.
Let’s create a basic script that performs a basic request on the http://blazedemo.com web page:
This load script is very simple but it is enough to show you the difference between different threads creation modes. For the first experiment, we will spin up 1000 users in 15 minutes with the “Delay Thread creation until needed” option turned off:
To measure resources’ allocation, we can just use a simple processes monitor available in any operating system out of the box:
As you can see, in our test environment, JMeter takes around 560MB memory by default. So what would it look like if we run the same script with the “Delay Thread creation until needed” option on?
Let’s illustrate the results distribution to visualize the difference:
As you can see, the patterns of both test executions are different. The red graph shows memory that was occupied when the delayed threads options was off. As you can see, right at the beginning of the script execution, the memory allocation spiked, while the same spike is less steep when the delayed threads options is on (in blue).
This is a visual demonstration of the “Delayed threads” feature that allows allocating memory for new threads only when they start their execution. As soon as all the threads are allocated and used in the script test execution, you will find that JMeter takes the same amount of memory (you can see that that memory allocation at the end of the script is almost the same).
But if the final amount of allocated memory is the same then why does makes sense to have both options? Let’s assume that you have long run test with slow users ramp-up.
First, it doesn’t sound wise that you don’t necessarily need to allocate memory for the threads that you are not actually running at this moment. What if you are running the script locally on your laptop over several hours? It doesn’t make sense to have a fully occupied memory during all this time as it produces laptop slowness and there is no point in reconciling this with this if it is redundant.
Second, what if you run your tests somewhere in a cluster with shared resources, which means that the RAM is shared across different services (servers) and if you occupy more on one machine (for running JMeter tests) then it immediately means that you have fewer resources for other services. This again doesn’t sound wise if there is no necessary need for this.
Finally, you might want to run a long running test and simulate as many threads as you can, but you don’t know your limits yet. You can try to run 5000 but what if this is not your limit and you can run more until you hit the memory limitation. In this situation, the “Delayed thread creation” feature allows you to specify more users than your machine can actually handle, and if you run the test it will not fail right away but only at the moment the script will simulate a number of users you cannot handle due to RAM limitation.
So, we get the main idea and the benefits that this feature gives us for free. But why then would we like to have both options and still have the ability to allocate memory for all the threads right away?
Actually, there is such a need. Mainly, it is required when you need to be 100% sure that you can handle the number of specified users. For example, you might have an exact requirement to measure the load under 10000 users, which will ramp up gradually in 8 hours. If you run this test using “Delayed thread creation” ON, you might be in a situation that you don’t have enough resources to run all the users but you will know it only after a long time, which will turn into a huge loss of time for you as you had the exact requirement to measure the load with 10000 users.
At this moment I see only this point which might enforce you to continue using JMeter with “Delayed thread creation” OFF. In all other situations, I would go with having this option ON because it sounds like a smart way to save some resources.
Do you have some other opinion on situations in which you might prefer one or another “Delayed thread creation” option? Please, you are welcome to share your thoughts below!
Learn more JMeter tips and hacks from our free JMeter academy.