skip to content

In JMeter's Precise Throughput Timer, what do the Batched departures settings actually do?

level: seniorimportance: nice to knowfreq 22%

answer

  1. One arrival, several threads
  2. The rate is divided before scheduling
  3. One of the two fields is inert
  4. Check what the generator actually reads

basics

~20 s

Number of threads in the batch releases that many threads on one scheduled arrival, and the timer divides the rate by the batch size so the average holds. The companion in-batch delay field is not applied in JMeter 6.0.0.

solid answer

~40 s

**Batched departures** turns single arrivals into packs. Setting **Number of threads in the batch (threads)** to `3` makes three threads leave the timer on one scheduled arrival; the generator divides the configured throughput by the batch size before building the schedule, so the average rate still matches Target throughput. The default of `1` means no batching. The second field, **Delay between threads in the batch (ms)**, is documented as spacing the members at x, x+42 ms, x+84 ms - but in Apache JMeter 6.0.0 nothing reads it when arrival times are computed. `ConstantPoissonProcessGenerator` stores the value behind a `// TODO: implement` comment, and every batch member after the first is handed the same scheduled timestamp as the first. In practice, treat a batch as simultaneous departures.

go deeper

for a junior

Know only that the default batch size of one means no batching, and that these two fields are about the shape of the arrivals rather than about how much load the timer asks for.

for a middle

Explain the division: the timer divides the throughput by the batch size before scheduling, so three-thread batches mean a third as many arrivals and the same total sample count.

for a senior

This is where the documented behaviour and 6.0.0's code part company. Saying the in-batch delay is not applied, and that batch members share one timestamp, shows you read past the tooltip.

for a principal

Treat a documented-but-inert setting as a risk to the team's plans: someone will set it, believe it, and build a conclusion on it. Decide whether such settings are banned or annotated in reviewed plans.

## What batching is for Some workloads do not arrive one at a time. If the thing you are modelling fires requests in pairs or triples, a Poisson schedule of single arrivals is the wrong shape even when its average rate is right. The Precise Throughput Timer's **Batched departures** group is its answer: instead of releasing one thread per scheduled arrival, release several. The manual notes that a Synchronizing Timer can solve some of these cases, but that this timer has a native way to issue requests in packs. ## The two fields - **Number of threads in the batch (threads)** - how many threads depart together. Default `1`, which disables batching. - **Delay between threads in the batch (ms)** - documented as the offset between members of a pack. Default `0`. The manual's own wording for the second field is precise: *if set to 42, and the batch size is 3, then threads will depart at x, x+42ms, x+84ms.* ## What the batch size really changes The important part is that batching does **not** raise the load. Before it generates the schedule, the timer divides the configured throughput by the batch size. So at 600 samples per 60 seconds with a batch size of 3, the generator schedules 200 arrivals instead of 600, and each one releases three threads. The count over the window is unchanged; only its shape is. That is why the field's description says the overall number of samples will still be in line with Target Throughput. Batching is a knob for burstiness, not for rate. ## What 6.0.0 does with the second field Here the documentation and the code disagree, and the code wins. In Apache JMeter 6.0.0: 1. The GUI accepts **Delay between threads in the batch (ms)** and the value is persisted with the element. 2. It is passed into `ConstantPoissonProcessGenerator`, where the field it lands in is marked `// TODO: implement` and is never read. 3. When the generator hands out arrivals, the first member of a batch advances to the next scheduled time and every later member is given that same timestamp back. The practical result is that all members of a batch are scheduled to depart at the same instant, whatever you type into the delay field. Threads will still not start at literally the same microsecond, because they are separate threads competing for the CPU, but nothing in the timer is spacing them. ## How to use this in a real plan - If you want packs, set **Number of threads in the batch** and accept simultaneous departures. - If you need a measured offset between the members of a pack, do not expect this field to provide it in 6.0.0; the shape has to come from somewhere else in the plan. - Remember the group needs enough threads for a whole batch to depart at once, otherwise the pack is served raggedly by whichever threads happen to be free. - Leave the batch size at `1` unless the workload genuinely arrives in packs; it is the kind of setting that quietly changes what a run means.

  • Does raising the batch size raise the overall rate of a Precise Throughput Timer?
    No. The generator divides the configured throughput by the batch size before generating arrivals, so the same number of samples is spread over fewer, larger departures. The batch size changes the shape of the load, not its average level.
  • How would you get a measured offset between the threads of one burst in 6.0.0?
    Not from the in-batch delay field, which is inert. The honest answer in an interview is that 6.0.0 gives you simultaneous departures from this timer, so any spacing inside a pack has to be modelled elsewhere in the plan rather than configured here.

saying these in an interview costs you the question

  • Expects batching to raise the overall rate
  • Believes the in-batch delay actually spaces the threads
  • Thinks a batch size of one still groups arrivals
  • Assumes batching needs no extra threads in the group
  • Confuses batched departures with a Synchronizing Timer