Example on constant throughput distribution - Performance Testing

A constant throughput timer is usually used to control throughput. You can use different computing modes based on business purposes of stress testing scripts. When you use distributed load generators for stress testing, you must properly configure parameter values and modes in a script to match different stress testing models. This topic describes two commonly used computing modes by scenario and the distributed adaptation performance of different computing modes.

Background information

The global and single distributed adaptation modes are available. In this example, two IP addresses are used to simulate 100 virtual users in a thread group. In the script, the target throughput is set to 100 requests per minute, and the computing mode is This Thread Only.

In global distributed adaptation mode, the threshold in the script applies as the total threshold of all load generators in the cluster. Threshold for a single load generator = Threshold in the script/Number of IP addresses. In this case, the total target throughput is calculated by using the following formula: 2 × (Virtual users/2) × (Target throughput/2) = 5,000 requests per minute.
In single distributed adaptation mode, the threshold in the script applies to each load generator. Note that the load level of the virtual users must match the configured value. In this case, the total target throughput is calculated by using the following formula: 2 × (Virtual users/2) × Target throughput = 10,000 requests per minute.

Scenarios

In most cases, you can configure the throughput threshold for a sampler, a thread group, or the whole scenario if multiple thread groups are available. We recommend that you do not configure the throughput threshold at a complex granularity. In this example, two IP addresses are used to simulate 100 virtual users in a thread group. In the script, the target throughput is set to 100 requests per minute.

Scenario 1: Configure the throughput threshold for a sampler

Log on to the PTS console, choose Performance Test > Create Scenario, and then click JMeter.
In the Advanced Settings section, select Single Generator for Constant Throughput Timer.
Note
Parameters in the Distributed Adaptation section on the Scenario Configuration tab are displayed only if a timer is configured in the script that you upload.
In the JMeter script, place Constant Throughput Timer under Sampler.
Set the Target Throughput parameter to 100, in minutes. Select this thread only for Calculate Throughput based on, as shown in the following figure.

Scenario 2: Configure the throughput threshold for a thread group

Log on to the PTS console, choose Performance Test > Create Scenario, and then click JMeter.
In the Advanced Settings section, select Global for Constant Throughput Timer.
Note
Parameters in the Distributed Adaptation section on the Scenario Configuration tab are displayed only if a timer is configured in the script that you upload.
In the JMeter script, place Constant Throughput Timer under Thread Group.
Set the Target Throughput parameter to 100, in minutes. Select all active threads in current thread group for Calculate Throughput based on, as shown in the following figure.

Five computing modes

In this example, one load generator is used to simulate two thread groups that contain 100 virtual users and 200 virtual users, respectively. Two samplers are configured for each thread group. In the script, the target throughput is set to 100 requests per minute.

Note

This example is for reference only. For more information, see the Apache JMeter documentation.

Computing mode	Description	Remarks
this thread only	The target throughput applies to each thread. The total throughput for a thread group is calculated by using the following formula: Virtual users × Target throughput.	No throughput is available for idle threads. You can calculate the throughput for each sampler by using the following formulas: Sampler 1.1 and Sampler 1.2 in Thread Group 1: Virtual users × Target throughput = 100 × 100/60 ≈ 166 requests per second. The throughput for each sampler is approximately 83 requests per second. Sampler 2.1 and Sampler 2.2 in Thread Group 2: Virtual users × Target throughput = 200 × 100/60 ≈ 320 requests per second. The throughput for each sampler is approximately 160 requests per second. You can configure the throughput for a single sampler to achieve sampler-level throughput control.
All active threads	The configured target throughput applies to all active threads in all thread groups. After a thread ends, the thread waits for a period of time and then runs again. This helps control the throughput.	If multiple thread groups are available, take note of the following items: The first sampler in a thread group runs first, and therefore the throughput of the second sampler is excessively low. The target throughput is configured at the thread group level. The throughput per thread is 1 request per minute and 2 requests per minute, respectively. As a result, the throughput for the second sampler decreases. The target throughput for each thread group is 100 requests per minute, and the global throughput is 200 requests per minute. After a period of running time, the number of requests sent by each sampler in a thread group is the same, which equals the number of virtual users. In this case, the sampler throughput in each thread group is balanced.
All active threads in current thread group	The configured target throughput applies to active threads in the current thread group. After a thread ends, the thread waits for a period of time and then runs again. This helps control the throughput.	If only one thread group is available, the same rules as the previous computing mode apply. Take note of the following items: The configurations of the two timers are the same. Therefore, the same rules as the previous computing mode apply. You can control the throughput of each thread group if you change the target throughput for the second timer to 200 requests per minute.
All active threads (shared)	The configured target throughput applies to all active threads in all thread groups. After all active threads end, all threads wait for a period of time and then run again. This helps control the throughput.	You can achieve similar performance when you select Delay from the Add Instruction drop-down list in the whole scenario. Threads can run again after all active threads end. Take note of the following items: During stress testing, data of multiple samplers does not change at the same time. The thread that has initiated requests is suspended on the first sampler. The target throughput for the whole scenario is 100 requests per minute, and the configurations of multiple timers are consistent.
All active threads in current thread group (shared)	The configured target throughput applies to all active threads in the current thread group. After all active threads end, all threads wait for a period of time and then run again. This helps control the throughput.	After all active threads in the current thread group end, the threads wait for a period of time and then run again. The target throughput for the current thread group is 100 requests per minute. Each thread runs based on collaboration with other active threads in the current thread group. You can separately configure and control the throughput for each thread group.

Distributed adaptation for other computing modes

Computing mode	Scenario	Global mode	Single mode
All active threads	This computing mode is suitable for a whole scenario in which the throughput is controlled. The business models of multiple thread groups are similar. The throughput of the whole scenario is fixed. This way, the throughput can be evenly distributed to each thread group.	A load generator is used to simulate 50 virtual users. The throughput of a load generator is 50 requests per minute, which is obtained by dividing the target throughput by 2. The global throughput remains 100 requests per minute. The throughput is accumulated if multiple thread groups are available.	A load generator is used to simulate 50 virtual users. The throughput of a load generator is 100 requests per minute. The global throughput is 200 requests per minute, which is obtained by multiplying the target throughput by the number of IP addresses. The throughput is accumulated if multiple thread groups are available.
All active threads (shared)	The throughput applies to the whole scenario but not thread groups. The throughput is slightly lower than the accumulated value of multiple thread groups.	The throughput is 100 requests per minute for Thread Group 1 and 200 requests per minute for Thread Group 2. The global throughput is 150 requests per minute, which is the average value of the two thread groups.	The throughput is 100 requests per minute for Thread Group 1 and 200 requests per minute for Thread Group 2. The throughput for a load generator is 150, which is calculated by using the following formula: (100 + 200)/2. The global throughput is 300 requests per minute. It takes a long period of time for multiple samplers of a load generator to reach balance.
All active threads in current thread group (shared)	The throughput applies to all active threads in a thread group. The global throughput is slightly lower than the accumulated value of multiple thread groups.	If the throughput is 100 requests per minute for Thread Group 1 and 200 requests per minute for Thread Group 2, the global throughput is 300 requests per minute, which is the accumulated value for Thread Group 1 and Thread Group 2.	If the throughput is 100 requests per minute for Thread Group 1 and 200 requests per minute for Thread Group 2, the throughput for a load generator is 300 requests per minute, and the global throughput is 600 requests per minute. It takes a short period of time for multiple samplers of a load generator to reach balance.