In-depth Analysis: Throughput Controller in JMeter and Splitting Threads to Requests

How Does Throughput Controller Work?

What the throughput controller basically does is; control the execution amount for its child requests. For example, in a script where a request is going to be called 100 times in total, it can be reduced up to 50 times with a throughput controller that has a 50% execution parameter. One thing worth mentioning, which is also mentioned in JMeter’s documentation; is that the throughput controller does not indicate exactly what its name implies, which is “requests executed per unit of time”. Instead, it does not have control over “per unit of time”, but this functionality is still somewhat parallel to what is usually wanted to perform, which is limiting the specific request’s execution amount.

For a more detailed examination of how the throughput controller controls execution times, let’s illustrate it with an example:

Let’s say we have a number of threads (virtual-users) set to 10 and add two throughput controllers with 50% execution. The first one is “Letters”, and the second one, “Numbers”. With this setup, JMeter will try to execute requests “A” and “1” 5 times each.

What is important here is, that if we take a look at the results of the execution, it can be seen that Thread#2 has executed both requests; “A” from “Letters”, and “1” from “Numbers”.

This means that, if we have a script that passes crucial information (variables) between the requests to execute another request, this behavior of JMeter may cause a logical error in the script.

For instance, let’s say we have a script for an e-commerce website, and we want to distribute users by paying online and paying on delivery. Information on a credit card will be required for paying online, and information about the person who is picking up the package will be required for paying on delivery. Furthermore, this information will be managed in the script by executing different requests with different parameters for each paying type. Therefore if we were to distribute users with only throughput controller, there is a possibility that thread#1, (let’s say online payer), which has information of a credit card stored in its variable will be executing a request for paying on delivery, which will cause an error in the script, and vice versa. Since the throughput controller’s purpose is to distribute the execution amount with the given parameters by selecting threads almost randomly, it will be ignoring the logical errors occurring in the script.

Alternatives & Solutions

One alternative could be using a switch controller instead and designing it to act like a throughput controller. For this, we need to create a .csv file for the switch controller to make it act like it randomly selects its child nodes, concerning the execution amounts we want it to achieve.

With this .csv file, the switch controller will be executing “Paying Online” and “Paying On Delivery” 5 times each, and the order can certainly be randomized if needed to achieve a more realistic simulation. Moreover, with this script design, the threads will be following one of either paths; “Paying Online” or “Paying on Delivery”.

When Should I Use A Throughput Controller?

As long as there isn’t a transfer of crucial information between requests, or the probability that some logical error might occur, using the throughput controller should not cause an issue.