In JMeter's Constant Throughput Timer, what does a Target Throughput of 600 ask for?
answer
- Read the unit inside the field label
- Sixty thousand milliseconds are in the arithmetic
- It counts samplers, not loop passes
- Default mode paces each thread alone
basics
~20 s600 samples per minute, not per second, so ten a second. The field's unit is per minute, and by default the rate applies to each thread on its own, counting every sampler in the timer's scope.
solid answer
~50 sJMeter labels the field **Target throughput (in samples per minute)**, so `600` means 600 samples a minute, which is ten a second. The timer turns the target into a gap by dividing 60000 ms by it, giving 100 ms of spacing at 600. Two details catch people out. First, the unit is **samples**, not iterations: a timer scoped above five HTTP Request samplers with a target of 600 paces 600 requests a minute, which is 120 passes through the five. Second, **Calculate Throughput based on** defaults to `this thread only`, so each thread aims at 600 a minute by itself and twenty threads aim at 12,000 between them. The element's own description calls the value a *maximum*: the timer only inserts pauses, so the target is a ceiling it approaches, never a rate it can force.
go deeper
Memorise the unit in the label: samples per minute. Divide by 60 to sanity-check against a per-second requirement, and say out loud that 600 means ten a second.
Explain the mechanics: 60000 ms divided by the target gives the spacing, the timer runs before each sampler in scope, and the default mode paces each thread separately rather than dividing the target.
Show that you convert the business number yourself: requests per iteration, threads, and mode all sit between the requirement and the value you type. Then say the timer only adds delay.
Own the convention. Decide whether team plans express the target per thread or group-wide, and whether the number in the field is a literal or a property, so plans are comparable across runs and injectors.
## The unit is baked into the label Apache JMeter's Constant Throughput Timer has exactly two fields, and the first is labelled **Target throughput (in samples per minute)**. The parenthesis is the whole answer: `600` means 600 samples every minute, which is ten a second. Nothing about the field is per second, and nothing about it is per hour. The timer turns that number into a gap by dividing 60000 milliseconds, one minute, by the target. At 600 the gap is 100 ms; at 60 it is 1000 ms; at 6 it is ten seconds. That gap is what the thread waits before its next sampler runs, so you type a rate and JMeter computes a delay from it. The element's own description repeats the unit and adds two more constraints in the same breath: *"Maximum number of samples you want to obtain per minute, per thread, from all affected samplers."* The three sections below take that sentence apart. ## Samples, not iterations Timers are processed before each sampler in the scope where they sit. Put a Constant Throughput Timer directly under a Thread Group that holds five HTTP Request samplers, set the target to 600, and you have asked for 600 **requests** a minute, which is 120 complete passes through the five samplers, not 600 passes. If the requirement you were handed is "600 checkouts an hour" and a checkout is five requests, you do that arithmetic yourself before typing anything. There is no field on the timer that switches it to counting iterations. ## Per thread, by default The second field, **Calculate Throughput based on**, defaults to `this thread only`. In that mode every thread paces itself to the full target independently, so the rate the group aims at is the target multiplied by the number of active threads: | Active threads | Calculate Throughput based on | Rate the group aims at | | --- | --- | --- | | 1 | `this thread only` | 600 / min | | 20 | `this thread only` | 12,000 / min | | 20 | `all active threads in current thread group` | 600 / min | | 20 | `all active threads in current thread group (shared)` | 600 / min | A plan tuned with one thread and then scaled to twenty silently asks for twenty times the load unless that dropdown is changed too. ## Maximum, not guarantee The word the description uses is *maximum*. A timer can only insert a pause; it cannot make a response arrive sooner and it cannot start another thread. The manual is blunt about the consequence: the throughput will be lower if the server cannot handle it, or if other timers and time-consuming elements in the same scope get in the way. The target is a ceiling the run approaches from below, not a floor it is held to. ## Things that follow from the unit - 600 a minute is ten a second, so the timer wants a sample started every 100 ms across whatever it is pacing. - The value need not be a literal. The manual allows a variable, a `__jexl3` or `__groovy` call, or a JMeter property changed mid-run, with the caveat that a new value takes a while to take effect. - The value is a `double`, so fractional targets are legal: `0.5` is one sample every two minutes. - In the `.jmx` file the target is a `doubleProp` named `throughput` and the mode a `stringProp` named `calcMode` holding one of `calcMode.1` through `calcMode.5`. ## The check to run before you trust the number Read the label out loud, then multiply it out: target, times active threads if the mode is `this thread only`, divided by the number of samplers in one iteration, gives iterations per minute. If that does not match the requirement you were given, the number in the box is wrong, not the tool.
- Can the Target Throughput field of JMeter's Constant Throughput Timer hold a variable or a function?Yes. The manual says the value need not be constant: it can be a variable, a `__jexl3` or `__groovy` call, or a JMeter property changed from the remote BeanShell server, and the timer re-reads it on every delay calculation. Change it sparingly, though, because the manual warns that a new value takes a while to take effect.
- With twenty threads on the default mode, what total rate does a Target Throughput of 600 aim at?About 12,000 samples a minute. In `this thread only` mode each thread paces itself to the full 600 a minute, so the group total is proportional to the number of active threads. To make 600 the group's total instead, pick one of the `all active threads` modes.
saying these in an interview costs you the question
- Reads 600 as 600 requests per second
- Expects 600 loop iterations rather than 600 samples
- Assumes the default splits the target across threads
- Believes the timer can speed a thread up
- Treats the target as a guaranteed rate