Details of Throughput Controller in JMeter (Splitting Threads to Different Requests)
PreviousHandling Error Messages of JMeter Tests in LoadiumNextHow to Add a Varying Number of Parameters in Apache JMeter
Last updated
Was this helpful?
Last updated
Was this helpful?
Throughput, essentially, is the number of requests executed per unit of time. It is one of the basic concepts of performance testing. Since the main subject here is “performance”, a term that features a measurement of “per unit of time” makes it an important one.
In performance tests, there will be a lot of requests going on in a short period of time in order to apply necessary stress to the desired servers. However, not every server in a system has an equal priority or necessity to apply stress. One of the servers might be called more frequently than others. For example, for an e-commerce website, a server that is responsible for completing a transaction will have much more load in general compared to the one that is responsible for creating an account. Therefore, it is unnecessary to apply the same load for every page, instead, the load should be split or even prevented from some servers. Generally, for this purpose, a tool in JMeter called “throughput controller” is used, however, this tool could sometimes lead to logical errors in the script.
What the throughput controller basically does is; controlling 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 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. First one; “Letters”, and second one; “Numbers”. With this setup, JMeter will try to execute requests “A” and “1” 5 times each.
What is important here is, 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 which passes crucial information (variables) between the requests in order 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 of credit card will be required for paying online, and information of 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 execution amount with the given parameters by selecting threads almost randomly, it will be ignoring the logical errors occurring in the script.
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 more realistic simulation. Moreover, with this script design, the threads will be following one of either path; “Paying Online” or “Paying on Delivery”.
As long as there isn’t a transfer of crucial information between requests, or probability that some logical error might occur, using the throughput controller should not cause an issue.
Happy testing!
If you don't see the answer to your question here, please reach out to us to let us know! We're always improving our documentation.
One alternative can be using a switch controller instead, and design it to act like a throughput controller. For this, we need to create a .csv file for switch controller to make it act like it randomly selects its child nodes, with respect to execution amounts we want it to achieve. .csv file:
