When it comes to building an advanced JMeter test plan, you can encounter the requirement to run certain samplers with a certain probability. For instance, if you are load testing an e-commerce web site, you may need to configure the following distribution:
- 40% of anonymous users browsing the website
- 30% of authenticated users doing the same
- 20% of users performing search
- 10% of users manipulating the shopping cart (i.e. adding, removing items, check-in/out, etc.)
In this post, we’ll guide you through the options on configuring weighted load and highlight options provided by JMeter.
As per JMeter 2.13, there are 3 options:
Using Different Thread Groups with a Different Number of Threads
Probably the easiest way to implement a distributed scenario when N% of users execute task A, M% of users do task B, etc. is setting up different test groups with the relevant percentage of virtual users configured. For example, given the aforementioned scenario with 40%-30%-20%-10% distribution, we’ll need 4 Thread Groups having 40, 30, 20 and 10 threads correspondingly. You can divide or multiply these numbers by any reasonable factor as per your load test plan; you just have to make sure that the factor is the same. So our Test Plan will have:
- Thread Group with 10 users
- Thread Group with 20 users
- Thread Group with 30 users
- Thread Group with 40 users
Use Aggregate Report Listener - to visualize tests results
Pay attention to status of “Run Thread Groups consecutively” checkbox on Test Plan level.
- If it’s checked - JMeter will execute the Thread Groups one by one upside down.
- If it’s unchecked - all Thread Groups will be executed simultaneously. Make sure that you double check this box state and that it reflects your test flow.
Now let’s run our test plan and see how it goes:
As seen in the above screenshot, the number of requests exactly matches our test action's distribution. The approach is fairly easy to implement and if your test logic is not very complicated, there won’t be too much overhead in the supporting the thread group per user scenario. In other words, from a perspective of parameterization, you can stick to this option.
But what about distribution requests in a single thread group? You’re welcome to continue reading to learn about more options.
Using Throughput Controller with Different Execution Percentages
Throughput Controller is a slightly misleading name as it does not control throughput (Constant Throughput Timer does - though to be fair “Constant Throughput Timer” does not necessarily need to be “constant” either, but that’s out of scope for this article). Instead of managing throughput, the controller defines how often its child elements are executed.
The Throughput Controller can operate in 2 modes:
- Total Executions - defines how many times the child elements will be executed (absolute number)
- If “Per User” is unchecked - the underlying sampler(s) will be executed as many times as defined in the “Throughput” field. For instance, if you have 100 users, the throughput of 100 and the box is unchecked, the underlying test elements will be executed 100 times.
- If “Per User” is checked - the child sampler(s) will be executed as many times as defined in the “Throughput” field, multiplied by the “Number of Threads” in the current Thread Group. For instance, if you have 100 users, the throughput of 100 and the box is checked, underlying test elements will be executed 100,000 times.
- Percent Executions - the child elements will be executed according to the percentage of iterations (threads * loops) as defined in the “Throughput” field.
A Test Plan that will produce a 10%-20%-30%-40% percent distribution being implemented via Throughput Controller will look like:
Thread Group (100 threads, 1 loop)
- Throughput Controller (Percent Execution, 10.0)
- Throughput Controller (Percent Execution, 20.0)
- Throughput Controller (Percent Execution, 30.0)
- Throughput Controller (Percent Execution, 40.0)
So the Test Plan will look something like:
Looking at the Aggregate Report after execution, it appears that the results are pretty much the same as for the different Thread Groups approach. However, only one Thread Group was used.
Using Switch Controller: Random Weighted Values
Another option to determining the defined samplers' execution percentage rate is using Switch Controller. Switch Controller provides the option to run one of its subordinate samplers based on the “Switch Value” which could be:
- An integer - the child element which is index based on the Switch Value will be executed. The numbering is zero-based. If there is no match or the Switch Value is blank/unset - the first child element will be executed.
- A string - the child element whose name equals the Switch Value string will be executed.
So given the below image:
- If the Switch Value is 0 - Sampler A is executed
- If the Switch Value is 1 - Sampler B is executed
- If the Switch Value is “Sampler A” - Sampler A is executed
- If the Switch Value is “Sampler B” - Sampler B is executed
So if we’re about to replicate the previous scenario with 10%-20%-30%-40% and bring a degree of “randomness”, we need to generate the appropriate Switch Values. So in order to achieve the following distribution:
- Sampler 10% - approximately 10% of executions
- Sampler 20% - approximately 20% of executions
- Sampler 30% - approximately 30% of executions
- Sampler 40% - approximately 40% of executions
We need to “tell” the Switch Controller somehow to trigger subordinate samplers.
- 0 Switch Value should occur 10% of iterations
- 1 Switch Value should occur 20% of iterations
- 3 Switch Value should occur 30% of iterations
- 4 Switch Value should occur 40% of iterations
The Full Test Plan for this scenario will look like:
Each thread coming to the Switch Controller will trigger a random Switch Value generation that will range from 0 to 3 and the relevant child sampler will be executed. It may be not as accurate as the Thread Groups and Throughput Controller methods, but it gives you a guarantee that only one of subordinate samplers is executed by each thread, and it allows randomizing the process of sampler selection. So, as can be seen from the Aggregate Report for the above scenario, a similar result can be achieved using the Switch Controller:
These are 3 ways of running samplers with defined and random probabilities - hopefully it covers the majority of use cases. If your test scenario is missing, please let us know via the comments form below the article and we’ll respond there or even update the post mentioning you as co-author.
You can use any above option in BlazeMeter systems as they have always been (and will be) 100% JMeter-compatible.
For experienced JMeter users, you'll want to view the on-demand webcast, How to Create Advanced Load Testing Scenarios with JMeter.
If you are new to JMeter, and you’d like to learn more, please sign up for our free online JMeter training course.
You might also find these useful:
Interested in writing for our Blog? Send us a pitch!