Constant Throughput Timer: Distributed usage examples-Performance Testing(PTS)-阿里云帮助中心

The Constant Throughput Timer is used to control the throughput of your test. You can choose a calculation mode based on the goals of your test script. When using distributed stress sources, you must consider the configuration values and modes in your script to match various performance testing models. This topic describes two common use cases and explains how the distributed adaptation settings work with different calculation modes.

Background information

The following examples illustrate how the distributed adaptation settings work. Assume a test scenario with two stress IPs, a concurrency of 100, and a single thread group in the script. The target throughput is 100 per minute, and the calculation mode is .

With the setting, the value from your script is treated as the total target for all stress machines combined. Performance Testing Service (PTS) automatically divides this target by the number of stress machines. In this case, the target for each machine is 50 per minute (100 / 2). The total throughput for the scene is 100 requests per minute.
With the setting, the value from your script is applied as the target for each individual stress machine. PTS does not modify this value. Ensure that the concurrency level matches your configured value. In this case, the total throughput for the scene is 200 requests per minute (100 per machine × 2 machines).

Common application scenarios

When configuring throughput control, we recommend applying it at either the sampler level or the thread group level. For a single thread group, controlling throughput at the thread group level affects the entire scene. Avoid overly complex configurations. The following examples use two stress machine IPs, a total concurrency of 100 in the thread group, and a target throughput of 100 per minute.

Control throughput at the sampler level

Log on to the PTS console. In the left navigation bar, select Performance Testing > Create Scenario, and then click JMeter.
On the scene configuration tab, in the Constant Throughput Timer section, select per machine.

Note The distributed adaptation settings section appears on the scene configuration tab only if a timer is configured in your uploaded script.
In your JMeter script, place the Constant Throughput Timer component as a child of the sampler you want to control.
Set Target throughput to 100 per minute. For Calculation mode, select this thread only, as shown in the following figure.

Control throughput at the thread group level

Log on to the PTS console. In the left navigation bar, select Performance Testing > Create Scenario, and then click JMeter.
On the scene configuration tab, in the Constant Throughput Timer section, select global.

Note The distributed adaptation settings section appears on the scene configuration tab only if a timer is configured in your uploaded script.
In your JMeter script, place the Constant Throughput Timer component as a child of a sampler within the thread group.
Set Target throughput to 100 per minute. For Calculation mode, select all active threads in current thread group, as shown in the following figure.

Five calculation modes

Example: Assume you are using a single stress source with two thread groups. Thread group 1 has a concurrency of 100, and thread group 2 has a concurrency of 200. Each thread group contains two samplers. The Target throughput for both is set to 100 per minute.

Note The following examples are for reference only. For detailed information, see the official documentation.

Calculation mode	Description	Details and example
this thread only	The target throughput is applied to each thread individually. The total throughput is the number of threads multiplied by the Target throughput value.	Inactive threads do not contribute to the throughput. Based on the example (requests per minute): Thread Group 1: Each thread sends 100 requests per minute. The total group throughput (10,000 req/min) is split between the two samplers, giving each a throughput of about 83 req/sec. Thread Group 2: Each thread sends 100 requests per minute. The total group throughput (20,000 req/min) is split between the two samplers, giving each a throughput of about 167 req/sec. Placing the timer under a specific sampler allows you to control the throughput for that individual sampler.
all active threads	The target throughput is shared among all active threads across all thread groups. Each thread pauses for a calculated delay after its last run to maintain the overall target.	When used with multiple thread groups, all timers should have the same configuration. In the example: This mode controls throughput at the thread level. As threads execute, the timer may significantly reduce the request rate for subsequent samplers within the same iteration to meet the overall target. Each thread group's timer is set to 100 per minute. The total effective throughput is the sum of the targets from all timers, which is 200 per minute. The throughput for each sampler within a thread group will balance out over time after the number of requests sent equals the number of concurrent threads.
all active threads in current thread group	The target throughput is shared among all active threads within the current thread group. Each thread pauses for a calculated delay after its last run.	In a single-thread-group scenario, this mode behaves identically to `all active threads`. In our two-group example: Because both timers have the same configuration, the behavior is similar to the `all active threads` mode. However, if you change the target throughput of the timer in the second thread group to 200 per minute, each thread group's throughput can be controlled independently.
all active threads (shared)	The target throughput is shared among all active threads across all thread groups. All threads wait until every active thread has completed its run before they pause and run again.	This creates a synchronized delay across the entire test plan. In this scenario: During the test, you will observe that samplers do not execute concurrently. Threads that have already sent a request will be paused by the timer. The overall target throughput for the entire test plan is 100 per minute, assuming both timers are configured with the same value.
all active threads in current thread group (shared)	The target throughput is shared among all active threads within the current thread group. All threads in the group wait until every active thread in that group has completed its run before they pause and run again.	Threads within a group are synchronized, pausing after all have completed their current sampler run. The target throughput for the thread group is 100 per minute. The throughput for each thread group can be configured and controlled independently.

Distributed adaptation for other calculation modes

Calculation mode	Use case	Global effect	Per-machine effect
all active threads	To control throughput for the entire test plan, where business models across multiple thread groups are similar and the total throughput is fixed.	The concurrency per machine is 50. The script's target throughput is divided by the number of machines, making the throughput on each machine 50 per minute. The total throughput remains 100 per minute. If there are multiple thread groups, their targets are cumulative.	The concurrency per machine is 50. The throughput on each machine is 100 per minute. The total throughput becomes 200 per minute (the script's value × number of machines). If there are multiple thread groups, their targets are cumulative.
all active threads (shared)	For controlling total throughput across all thread groups, where the target is slightly less than the sum of individual configurations.	If Thread Group 1 is set to 100 and Thread Group 2 is set to 200, the total throughput is the average of the two configurations (150).	If Thread Group 1 is set to 100 and Thread Group 2 is set to 200, the throughput per machine is 150 ((100 + 200) / 2). The total throughput is 300. It takes longer for samplers on each machine to reach a balanced state.
all active threads in current thread group (shared)	To control thread group throughput when the result is slightly less than the sum of individual configurations.	If Thread Group 1 is set to 100 and Thread Group 2 is set to 200, the total throughput is the sum of the configurations (300).	If Thread Group 1 is set to 100 and Thread Group 2 is set to 200, the throughput per machine is 300 (100 + 200). The total throughput is 600. It takes less time for samplers on each machine to reach a balanced state.