In JMeter's Constant Throughput Timer, what do the five Calculate Throughput based on options do?

middlemust knowfreq 58%

answer

Ask what the target is divided by
Two of the five say shared
Active threads counted right now
The default keeps each thread independent

basics

~20 s

They choose what the target rate is divided among: this thread alone, the current thread group, or every thread group, and whether each thread paces off its own last sample or off one clock shared by all of them.

solid answer

~60 s

Calculate Throughput based on picks the divisor for the target.

this thread only (the default) — every thread aims at the full target, so the group rate rises with the number of active threads.
all active threads in current thread group — the target is split across that group's active threads, each delaying from when it last ran.
all active threads — the target is split across active threads in every Thread Group, so each other group needs its own timer with the same settings.
all active threads (shared) and all active threads in current thread group (shared) — the same two scopes, but every thread takes the next slot from one shared scheduled time rather than pacing off its own last sample.

The divisor is the count of active threads at that instant, not the configured thread count, so it grows during ramp-up. The manual says the shared algorithm gives a more accurate overall rate and the non-shared one a more even spread across threads.

**Calculate Throughput based on** picks the divisor for the target. - `this thread only` (the default) — every thread aims at the full target, so the group rate rises with the number of active threads. - `all active threads in current thread group` — the target is split across that group's active threads, each delaying from when it last ran. - `all active threads` — the target is split across active threads in every Thread Group, so each other group needs its own timer with the same settings. - `all active threads (shared)` and `all active threads in current thread group (shared)` — the same two scopes, but every thread takes the next slot from one shared scheduled time rather than pacing off its own last sample. The divisor is the count of **active** threads at that instant, not the configured thread count, so it grows during ramp-up. The manual says the shared algorithm gives a more accurate overall rate and the non-shared one a more even spread across threads.

code

xml · 9 lines

xml

<ConstantThroughputTimer guiclass="TestBeanGUI" testclass="ConstantThroughputTimer" testname="Constant Throughput Timer" enabled="true">
  <stringProp name="calcMode">calcMode.5</stringProp>
  <doubleProp>
    <name>throughput</name>
    <value>600.0</value>
    <savedValue>0.0</savedValue>
  </doubleProp>
</ConstantThroughputTimer>
<hashTree/>

go deeper

for a junior

Know that the dropdown exists and that the default is this thread only. That single fact explains most cases of a plan producing far more load than the number in the field suggests.

for a middle

Explain the divisor: non-shared modes multiply the base gap by the active thread count, shared modes hand out slots from one clock. Mention that the count is active threads, not configured ones.

for a senior

Bring up the cross-group trap and ramp-up behaviour: all active threads divides by threads it does not pace, and the divisor moves while the group is starting and finishing.

for a principal

Decide the house convention. Picking group-wide shared mode everywhere makes plans comparable and reviewable; per-thread mode makes rates depend on thread count, which is a footgun when plans are scaled or split across injectors.

What the dropdown actually changes

The Constant Throughput Timer computes one number per call: how many milliseconds to wait before the next sampler in its scope. The base figure is 60000 / target, the millisecond gap that one sampler stream would need to hit the target on its own. Calculate Throughput based on decides how that base figure is adjusted for the fact that many threads are calling the same timer.

In the .jmx file the choice is stored as a stringProp named calcMode, and the five values are literally calcMode.1 through calcMode.5.

The five values

Dropdown label	Stored value	Effect on the wait
`this thread only`	`calcMode.1`	the base gap, unchanged; the default
`all active threads`	`calcMode.2`	base gap multiplied by the active threads in the whole test
`all active threads in current thread group`	`calcMode.3`	base gap multiplied by the active threads in this group
`all active threads (shared)`	`calcMode.4`	next slot from one clock shared by the whole test
`all active threads in current thread group (shared)`	`calcMode.5`	next slot from one clock shared by this group

The non-shared modes multiply because each thread is pacing itself: if twenty threads each wait twenty times the base gap, twenty streams together produce roughly one sample per base gap.

Shared versus non-shared

The shared modes do not multiply at all. They keep one scheduled time, advance it by the base gap on every call, and hand the caller the difference between that slot and now. Whichever thread asks next gets the next slot, so the arrivals interleave rather than being fixed per thread.

Non-shared — a thread that has just run waits a full multiplied gap, which spreads samples evenly across threads. The manual: the non-shared algorithm should generate a more even spread of transactions across threads.
Shared — a thread that is free takes the next slot regardless of when it last ran. The manual: the shared algorithm should generate a more accurate overall transaction rate.

Both aim at the same rate. Choose shared when the group total is what the requirement names, non-shared when you also care that each thread carries a similar share.

Active, not configured

The multiplier in all active threads modes is the number of threads currently running, not the number typed into the Thread Group. Two consequences follow:

During ramp-up the divisor grows as threads start, so the per-thread wait grows with it and the group rate stays near the target instead of overshooting at the start.
As threads finish at the end of a run, the divisor shrinks and the survivors speed up to keep the group rate near the target.

The cross-group trap

all active threads divides by threads in every Thread Group, but the timer still only delays the threads in its own scope. The manual states the consequence directly: in this mode, each other Thread Group needs a Constant Throughput Timer with the same settings. A plan with three groups and one timer in all active threads mode paces one group very slowly, because it divides by all the threads, and leaves the other two entirely unpaced.

Choosing

One group, and the requirement is a group total: use one of the current thread group modes.
One group, and each thread represents an independent user with its own rate: this thread only.
Several groups sharing one budget: all active threads, with an identically configured timer in every group.
Accuracy of the aggregate matters more than fairness between threads: add (shared).

## What the dropdown actually changes The Constant Throughput Timer computes one number per call: how many milliseconds to wait before the next sampler in its scope. The base figure is `60000 / target`, the millisecond gap that one sampler stream would need to hit the target on its own. **Calculate Throughput based on** decides how that base figure is adjusted for the fact that many threads are calling the same timer. In the `.jmx` file the choice is stored as a `stringProp` named `calcMode`, and the five values are literally `calcMode.1` through `calcMode.5`. ## The five values | Dropdown label | Stored value | Effect on the wait | | --- | --- | --- | | `this thread only` | `calcMode.1` | the base gap, unchanged; the default | | `all active threads` | `calcMode.2` | base gap multiplied by the active threads in the whole test | | `all active threads in current thread group` | `calcMode.3` | base gap multiplied by the active threads in this group | | `all active threads (shared)` | `calcMode.4` | next slot from one clock shared by the whole test | | `all active threads in current thread group (shared)` | `calcMode.5` | next slot from one clock shared by this group | The non-shared modes multiply because each thread is pacing itself: if twenty threads each wait twenty times the base gap, twenty streams together produce roughly one sample per base gap. ## Shared versus non-shared The shared modes do not multiply at all. They keep one scheduled time, advance it by the base gap on every call, and hand the caller the difference between that slot and now. Whichever thread asks next gets the next slot, so the arrivals interleave rather than being fixed per thread. - **Non-shared** — a thread that has just run waits a full multiplied gap, which spreads samples evenly across threads. The manual: the non-shared algorithm should generate a more even spread of transactions across threads. - **Shared** — a thread that is free takes the next slot regardless of when it last ran. The manual: the shared algorithm should generate a more accurate overall transaction rate. Both aim at the same rate. Choose shared when the group total is what the requirement names, non-shared when you also care that each thread carries a similar share. ## Active, not configured The multiplier in `all active threads` modes is the number of threads **currently running**, not the number typed into the Thread Group. Two consequences follow: 1. During ramp-up the divisor grows as threads start, so the per-thread wait grows with it and the group rate stays near the target instead of overshooting at the start. 2. As threads finish at the end of a run, the divisor shrinks and the survivors speed up to keep the group rate near the target. ## The cross-group trap `all active threads` divides by threads in every Thread Group, but the timer still only delays the threads in its own scope. The manual states the consequence directly: in this mode, each other Thread Group needs a Constant Throughput Timer with the same settings. A plan with three groups and one timer in `all active threads` mode paces one group very slowly, because it divides by all the threads, and leaves the other two entirely unpaced. ## Choosing - One group, and the requirement is a group total: use one of the current thread group modes. - One group, and each thread represents an independent user with its own rate: `this thread only`. - Several groups sharing one budget: `all active threads`, with an identically configured timer in every group. - Accuracy of the aggregate matters more than fairness between threads: add `(shared)`.

Why does one Constant Throughput Timer in all active threads mode not pace a second Thread Group?
The mode only changes the divisor; the timer still delays only the threads in its own scope. The manual is explicit that with `all active threads` each other Thread Group needs its own Constant Throughput Timer configured the same way, or its threads run unpaced while the paced group is slowed by their thread count.
What does a shared mode do differently from its non-shared twin?
Both aim at the same rate. A non-shared mode delays each thread from when that thread last ran, spreading samples evenly across threads. A shared mode advances one common scheduled time by the per-sample gap and gives each caller the next slot, which the manual says produces a more accurate overall rate.

saying these in an interview costs you the question

Thinks the default divides the target across threads
Uses all active threads with a timer in only one group
Assumes the divisor is the configured Number of Threads
Believes shared and non-shared aim at different rates
Expects the mode to change which samplers are paced

In JMeter's Constant Throughput Timer, what do the five Calculate Throughput based on options do?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

What the dropdown actually changes

The five values

Shared versus non-shared

Active, not configured

The cross-group trap

Choosing

▾common follow-ups2 questions

▾red flags5 flags

What the dropdown actually changes

The five values

Shared versus non-shared

Active, not configured

The cross-group trap

Choosing

answer

go deeper