skip to content

In JMeter's Precise Throughput Timer, what do Target throughput, Throughput period and Test duration set?

level: middleimportance: should knowfreq 48%

answer

  1. Two fields together make one rate
  2. Seconds sit in the denominator
  3. One of the three is only a hint
  4. The defaults are built around an hour

basics

~20 s

Target throughput divided by Throughput period is the arrival rate, so 600 over 60 seconds is ten a second. Test duration is the window the timer builds a schedule for; it does not end the test.

solid answer

~50 s

The Precise Throughput Timer expresses a rate as a pair: **Target throughput (in samples per "throughput period")** over **Throughput period (seconds)**. `600` over `60` and `36000` over `3600` are the same ten-a-second rate, and the manual advises picking whichever pair mirrors the requirement people actually wrote down. **Test duration (seconds)** is the window the timer generates arrivals for: it builds a schedule of rate x duration samples at startup and generates the next window when that one is exhausted. The manual says outright that it does *not* limit the test; it is a hint that makes the sample count per window come out round. Defaults are `100`, `3600` and `3600`. Unlike the Constant Throughput Timer's default, the schedule belongs to the Thread Group: every thread in the group draws its arrivals from the same Poisson schedule.

code

text · 1 line
text
2026-09-09 10:15:02,441 INFO o.a.j.t.p.ConstantPoissonProcessGenerator: Generated 600 timings (Precise Throughput Timer 600 required, rate 10.0, duration 60) in 1 ms. First 15 events will be fired at: 0.1436 (+0.1436), 0.4021 (+0.2585), 0.4877 (+0.0856), ...

go deeper

for a junior

Learn the pair: samples over a period in seconds. Say that 600 over 60 is ten a second, and that the third field is about the schedule, not about stopping the test.

for a middle

Explain that the timer builds a schedule of rate times duration arrivals up front and regenerates it when exhausted, and that the rate is shared by the whole Thread Group rather than applied per thread.

for a senior

Bring the operational detail: schedule memory for long windows, the advice to zero ramp-up and delay, and that the timer stops a thread rather than scheduling it past its own end time.

for a principal

Decide how rates are expressed across the team's plans. Choosing the throughput-over-period pair that matches the written requirement is what keeps a test report legible to the people who set the target.

## A rate expressed as two numbers Where the Constant Throughput Timer fixes the unit at samples per minute, the Precise Throughput Timer lets you name the period. Two fields make the rate: - **Target throughput (in samples per "throughput period")** - how many samples. - **Throughput period (seconds)** - the window those samples belong to. The timer divides one by the other to get a per-second rate. `600 / 60`, `10 / 1` and `36000 / 3600` are all ten a second, and the manual's advice is to pick the pair that reads like the requirement: 60 over 3600 for "60 samples per hour", 1 over 60 for "1 sample per minute". The number a stakeholder recognises is the one that should be in the field. The field's own description is explicit about scope: the target counts *all threads in the group, from all affected samplers*. This is the opposite of the Constant Throughput Timer's default, which paces each thread separately. ## Test duration is a scheduling window, not a stop **Test duration (seconds)** is the field that surprises people. It exists so that the timer can promise an exact count: over that window it generates `rate x duration` arrivals. The manual states the consequence in bold terms: *Test duration (seconds) does not limit test duration. It is just a hint for the timer.* What actually happens is that the timer builds a schedule for one window at startup, hands arrivals out of it as threads ask, and generates the next window when the current one runs out. So a five-minute run against a 60-per-hour rate is configured with a Test duration of 300 if you want exactly five samples in it, and a two-week run at 5000 per hour is better off with a one-hour window, giving exactly 5000 an hour: a two-week window would build a single schedule of 1,680,000 arrivals (rate x duration), past the million-sample line the manual warns about and around 13 MB of heap. (The manual's own worked example prints 168,000 here, but its arithmetic quietly uses 500 an hour.) ## The defaults, and what they encode | Field | Default | Meaning at the default | | --- | --- | --- | | Target throughput | `100` | 100 samples... | | Throughput period (seconds) | `3600` | ...per hour | | Test duration (seconds) | `3600` | schedule built one hour at a time | | Number of threads in the batch | `1` | batching off | | Delay between threads in the batch (ms) | `0` | no offset inside a batch | | Random seed | `0` | a fresh random sequence each run | The hour-shaped defaults are a hint about the timer's intended use: business-facing rates such as "reports per hour", not high-frequency load. The manual says it works best for rates under 36,000 requests an hour, which is exactly ten a second. ## One schedule per Thread Group The arrivals are Poisson-distributed rather than evenly spaced, which is why the manual contrasts it with the Constant Throughput Timer: that one *converges to the specified rate, however it tends to produce samples at even intervals*. The Precise Throughput Timer instead scatters arrivals inside the window while still landing the exact count. Because the schedule is held per Thread Group and shared by its threads, the timer does not multiply by thread count the way a per-thread mode does. It also means the schedule is a memory cost: the manual quotes roughly 8 MB and 200 ms for a schedule of a million samples, and about 80 MB for ten million. ## Ramp-up, and what 6.0.0 changed Because arrivals are already scattered, the manual recommends setting the Thread Group's Ramp-up Period **and** Delay to `0` when using this timer: the timer removes the startup spike that ramp-up exists to smooth, and a long ramp-up instead leaves too few threads available to serve the early arrivals. In Apache JMeter 6.0.0 the timer computes its delays relative to the **start of the Thread Group** rather than the start of the test. In a plan whose groups do not all start together, that is the difference between a schedule anchored to each group and one anchored to the run. ## The thing it still cannot do The manual is careful to say the timer *does not generate threads*. If the group has too few threads, or the samplers take too long, the achieved rate falls below the schedule exactly as it would with the Constant Throughput Timer. When a scheduled arrival would fall after the thread's scheduled end time, the timer stops that thread rather than waiting past it.

  • Does the Precise Throughput Timer's Test duration field stop the test when it expires?
    No. The manual states plainly that Test duration (seconds) does not limit the test; it is a hint that lets the timer produce exactly rate times duration arrivals in one window. When that schedule is exhausted the timer generates the next window and the run carries on.
  • Why does the manual recommend Ramp-up Period and Delay of 0 with this timer?
    Because the timer already scatters arrivals across the window, so there is no startup spike for a ramp-up to smooth. A long ramp-up instead leaves too few threads available at the beginning to serve the arrivals the schedule has already placed there.
  • Is 600 over 60 different from 36000 over 3600?
    Not as a rate; both are ten samples a second. They differ in what the schedule window and the round numbers in the report look like, and the manual's advice is to choose the pair that matches how the requirement was written so the figures stay recognisable.

saying these in an interview costs you the question

  • Thinks Test duration ends the run
  • Reads Target throughput as a per-minute figure
  • Expects each thread to get the full rate
  • Assumes the arrivals are evenly spaced
  • Believes 600 over 60 differs from 36000 over 3600