In JMeter's Open Model Thread Group, what does a pause(2 min) step do to the arrival rate?

## What the step is `pause(<number> <unit>)` is one of the four step kinds in the Schedule field of JMeter's Open Model Thread Group. It occupies time like an arrivals span does, but it schedules no new arrivals inside itself. Threads that were already started keep running; nothing new is launched. ## The rate comes back afterwards The behaviour people get wrong is what the schedule does *after* the pause. It resumes at the rate that was in force before it. Internally the parser desugars a `pause(d)` written after `rate(r)` into five steps: 1. `rate(r)` — close off the segment at the rate that was running, 2. `rate(0)` — drop to nothing, 3. an **even-arrivals span of length `d`** — the quiet stretch itself, 4. `rate(0)` — still nothing at the far end, 5. `rate(r)` — put the old rate back. Because both ends of the quiet span are zero, the span generates no arrivals at all. And because the fifth step reinstates `r`, the next span you write starts from `r` without you repeating it. If the rate before the pause was already zero, the rewrite collapses to just the span and the zero rate. The manual's own worked example is `rate(2/sec) random_arrivals(5 sec) pause(5 sec) random_arrivals(5 sec)`: two arrivals per second, then five seconds with no new arrivals, then five more seconds at two arrivals per second. ## A pause is always honoured A pause counts toward the thread group's total duration, and JMeter waits it out whether or not there is anything left to do. The manual states the consequence bluntly: with `rate(1/sec) random_arrivals(1 min) pause(1 hour)` the thread group lasts sixty-one minutes no matter how quickly the individual iterations finish. The starter logs `There will be no more events, so will wait for ... sec till the end of the schedule` while it does so. That cuts both ways: - **Useful**, because the thread group tears its threads down as soon as the schedule ends, so a trailing pause is the documented way to give slow iterations room to finish. - **A trap**, because a generous trailing pause is dead wall-clock time in every CI run, and a pause in the middle of a profile extends the run by exactly its own length. ## Where the duration shows up The GUI's summary line under the Schedule box — `Total duration: ..., max rate: ...` — already includes every pause, so you can read the real wall-clock cost of a profile before starting it. The `max rate` figure, by contrast, is taken from the rate steps only, so a long pause never changes it. ## Writing a hold-then-pause profile A profile that holds a rate, goes quiet, and picks the rate back up is the case this step exists for. Written out one step per line, with a comment: - `rate(50/sec) random_arrivals(10 min)` — hold fifty per second for ten minutes, - `pause(2 min)` — two minutes with no new arrivals, - `random_arrivals(10 min)` — ten more minutes, still at fifty per second, - `pause(5 min)` — headroom so the last arrivals are not interrupted. The third line needs no rate step of its own precisely because the pause restored the fifty. ## Things that are not true of pause - It does **not** reset the schedule to the implicit zero that a schedule starts at. - It does **not** stop or interrupt threads that are already running; it only stops new arrivals being created. - It is **not** skipped when nothing is running — an empty pause still costs its full duration. - It is not a think time between iterations. Each arrival in this thread group runs its children once and exits, so there is no gap between iterations for a pause to sit in.