skip to content

In a JMeter Open Model schedule, how does even_arrivals differ from random_arrivals?

level: middleimportance: nice to knowfreq 24%

answer

  1. Two arrivals steps, one grammar
  2. The difference is placement, not volume
  3. Only one of them looks at the seed
  4. One of them is stale in the manual
  5. A pause compiles into one of these

basics

~20 s

Both take a duration and interpolate between the rate before and the rate after them. Only placement differs: random_arrivals scatters the arrival instants using the thread group's generator, while even_arrivals spaces them evenly from the start of the span.

solid answer

~40 s

The two steps are interchangeable in syntax — `random_arrivals(2 min)` and `even_arrivals(2 min)` are parsed the same way, take the same time units, and take their start and end rates from the neighbouring `rate(...)` steps in the same way. Only the placement of instants inside the span differs. `random_arrivals` draws its instants from the generator built from the Random Seed field. `even_arrivals` computes them: for a flat span the first arrival is at the start and the rest follow at equal intervals, and for a ramping span the intervals shorten or lengthen smoothly. Two consequences follow. `even_arrivals` ignores the Random Seed entirely, and `pause(d)` is itself compiled into an `even_arrivals` span held between two zero rates.

go deeper

for a junior

Recall that a schedule has two arrivals steps with the same syntax, and that the choice between them changes how the arrivals are spaced rather than how many there are.

for a middle

Explain that both take their rates from the neighbouring steps and schedule the same count, and that only random_arrivals consults the generator built from the Random Seed.

for a senior

Show that you check the code or the behaviour rather than trusting a stale manual note, and that you know a pause is itself an even-arrivals span at zero rate.

for a principal

Own the documentation risk: when a component is still labelled experimental, its manual can lag its behaviour, so a team convention should say which step your plans use and why.

## Same shape, different placement The Schedule field of JMeter's Open Model Thread Group has two arrivals steps, and they are twins as far as the grammar is concerned: - both take one duration argument with the same units (`ms`, `sec`, `min`, `hour`, `day`, plus the single letters `s`, `m`, `h`, `d`), and both accept a compound duration such as `2d 1m 30s`; - both take their start rate from the `rate(...)` before them and their end rate from the `rate(...)` after them, defaulting the end rate to the start rate when none follows; - both schedule the same number of arrivals — the mean of the two rates times the duration, truncated. What differs is *where inside the span* those arrivals land. | Step | Placement | Uses Random Seed | |---|---|---| | `random_arrivals(d)` | instants drawn from the group's generator | yes | | `even_arrivals(d)` | instants computed at equal intervals | no | ## What even placement looks like For a flat span, `even_arrivals` puts the first arrival at the very start of the span and the rest at a constant interval afterwards — a span of `rate(1/sec) even_arrivals(2 sec) rate(1/sec)` yields arrivals at 0 and 1 second. Where the rates differ, the interval shortens as the rate climbs and stretches as it falls, so the arrivals still trace the ramp you asked for, just without scatter. Because nothing random is involved, the instants are identical on every run whatever the Random Seed says. ## The stale note in the manual The component reference for the Open Model Thread Group still annotates `even_arrivals` with "TODO: not implemented yet". At 6.0.0 that note no longer matches the code, and it is worth knowing which to believe: 1. The schedule parser recognises `even_arrivals` and produces a step whose arrival type is `EVEN`; an unrecognised name is a parse error naming the step kinds it does accept. 2. The process generator dispatches an `EVEN` span to the even-arrivals ramp and produces real timestamps for it, which the project's own tests assert. 3. JMeter itself emits the step: the GUI's plan-validation action rewrites an Open Model Thread Group's schedule to `rate(N / sec) even_arrivals(1 sec) pause(1 hour)`. 4. `pause(d)` is compiled into an `even_arrivals` span between two zero rates, so every schedule containing a pause already exercises the step. The honest summary for an interview is that the step works, and that the manual's TODO is documentation lag rather than a warning to avoid it. ## Where each one shows up - **`random_arrivals`** is what the GUI's own template button pastes and what the manual's examples use throughout, so it is what you will find in most plans. - **`even_arrivals`** is what you write when you want the arrival instants themselves to be fixed and repeatable without depending on a seed, and it is what JMeter reaches for internally when it needs a schedule to be predictable. ## Two things not to say - Do not say `even_arrivals` is unimplemented on the strength of the manual note alone — it parses, generates and is used by JMeter's own validation path. - Do not say the two steps differ in how much load they apply. They schedule the same number of arrivals for the same rates and duration; only the spacing differs. Which of the two suits a given run is a workload-design question rather than a JMeter one, and it belongs with the performance-testing fundamentals rather than with this element. What is squarely JMeter's is the pair of step names, the fact that they are otherwise interchangeable, and the fact that only one of them looks at the Random Seed.

  • Does even_arrivals respond to the Open Model Thread Group's Random Seed field?
    No. Its instants are computed from the span's start rate, end rate and duration, so they are the same on every run whatever the seed holds. Only random_arrivals draws from the generator the seed builds.
  • Where does an even-arrivals span turn up in a schedule that never mentions even_arrivals?
    Inside every pause. The parser compiles pause(d) into an even-arrivals span of length d held between two zero rates, which is why it schedules nothing and why the rate before it is reinstated afterwards.

saying these in an interview costs you the question

  • Says even_arrivals does not work at all
  • Claims the two steps apply different amounts of load
  • Thinks even_arrivals still honours the Random Seed
  • Believes only random_arrivals accepts compound durations
  • Assumes a pause is unrelated to either step