In JMeter's Open Model Thread Group, what does the Schedule rate(10/sec) random_arrivals(5 min) run?
answer
- One text field carries the whole profile
- Two kinds of step: levels and spans
- A span sits between two rate steps
- Look at what follows random_arrivals
- Implicit rate at the start is zero
basics
~20 sA flat ten arrivals per second for five minutes. The rate step names the arrival rate, random_arrivals spans five minutes, and because no rate follows the span its end rate is taken to equal its start rate.
solid answer
~50 sThe **Schedule** field of JMeter's Open Model Thread Group holds a small expression language, and JMeter parses it once when the group starts. `rate(...)` is a *level*: it contributes no time, it just names the arrival rate that applies where it is written. `random_arrivals(...)` is a *span*: it contributes duration, and it interpolates between the rate written before it and the rate written after it. Here the rate before the span is ten per second and nothing follows the span, so JMeter uses the same value as the end rate — the load is flat at ten arrivals per second for five minutes, about 3,000 arrivals in total. Writing `rate(10/sec) random_arrivals(5 min) rate(10/sec)` means exactly the same thing. Change the trailing step to `rate(20/sec)` and the same span becomes a linear rise from ten to twenty per second.
go deeper
Recall that the Schedule field is a small expression, not a number, and that rate names an arrival rate while random_arrivals names how long that segment lasts.
Explain how a span takes its start rate from the step before it and its end rate from the step after it, and why an omitted trailing rate produces a flat segment rather than a ramp to zero.
Show that you check a profile before running it: read the GUI's total-duration and max-rate summary, watch for the parse error replacing it, and remember the expression is fixed once the group starts.
Own the consequence that this element states a target arrival rate rather than a population, so a plan written this way declares its intent in one reviewable line that survives being handed to another team.
## The element's whole load definition is one text field JMeter's Open Model Thread Group is a core component (it ships in the Apache download, no plugin), and the manual still marks it experimental. Its component reference lists only three properties: **Name**, **Schedule** and **Random Seed**. There is no thread-count box and no loop-count box — the Schedule string *is* the load profile, and JMeter parses it exactly once, when the thread group starts. The parser recognises four step kinds plus comments: - **`rate(<number>/<unit>)`** — a *level*. It occupies no time; it names an arrival rate at the point where it is written. - **`random_arrivals(<number> <unit>)`** — a *span*. It occupies time and places arrivals at random instants inside itself. - **`even_arrivals(<number> <unit>)`** — a span that spaces its arrivals evenly. - **`pause(<number> <unit>)`** — a span during which no new arrivals are scheduled. - `/* block comments */` and `// line comments`, which are handy for disabling a step. ## How a span picks up its two rates Every span sits between two rates. The rate *before* it is the start rate; the next `rate(...)` step *after* it, if there is one, is the end rate. If no rate follows, the end rate is set equal to the start rate, so the span is flat. The implicit rate at the very beginning of a schedule is `0`. That rule is what makes the schedule in the question flat: | Schedule | What it applies | |---|---| | `rate(10/sec) random_arrivals(1 min) rate(10/sec)` | flat ten per second for a minute | | `rate(10/sec) random_arrivals(1 min)` | the same — the trailing rate is implied | | `rate(0) random_arrivals(1 min) rate(10/sec)` | linear rise from zero to ten per second | | `rate(3/sec) random_arrivals(1 min) random_arrivals(2 min) rate(6/sec)` | flat three per second, then three rising to six | The last row shows the other half of the rule: two spans back to back means the first one has no rate after it, so the first minute is flat and only the second span ramps. ## How many arrivals a span produces JMeter takes the mean of the start and end rates, multiplies by the span duration and truncates. A flat span of ten per second over five minutes therefore schedules `10 * 300 = 3000` arrivals; a span rising from zero to ten per second over a minute schedules `(0 + 10) / 2 * 60 = 300`. Truncation is deliberate so that the generated instants never spill past the end of the span. ## Units, numbers and spellings the parser accepts - Time units are `ms`, `sec`, `min`, `hour` and `day`. The single letters `s`, `m`, `h` and `d` parse too — note that `m` is minutes and `ms` is milliseconds. - Rates are normalised internally to arrivals per second: `rate(36000/hour)` and `rate(10/sec)` are the same step, and `rate(48/min)` becomes 0.8 per second. A rate that does not divide evenly keeps its fraction — `rate(50/min)` is 0.8333… per second; only the parser's debug `toString` rounds that to `Rate(0.8)`. - The `/` may be spelled as the word `per`: `rate(0 per min)` is legal. - Fractional rates parse: `rate(50.1/sec)`. - A rate of zero may omit its unit — `rate(0)` — because zero is zero in any unit. Any non-zero rate must carry one. - Durations may be compound and are summed: `even_arrivals(2d 1m 30s)`. A duration of `0` may omit its unit. - Whitespace and newlines are free, so a long profile can be laid out one step per line. ## What the GUI tells you while you type Under the Schedule box the GUI prints a summary in the form `Total duration: ..., max rate: ...` and draws a target-rate chart of the profile, and four template buttons paste `rate(1/min)`, `random_arrivals(10 min)`, `pause(1 min)` and `/* comment */` at the caret. If the expression does not parse, the parser's own message — which names the offending position and the text at it — replaces the summary. That is the fastest way to check a profile before running it. ## Two consequences worth carrying away 1. Because the expression is parsed once at start, the profile cannot change while the test runs. 2. Because the rate is a property of the *schedule* and not of any thread, nothing in the group's fields tells you how many threads will exist; that follows from the schedule you wrote.
- What does rate(0) random_arrivals(1 min) rate(10/sec) apply in an Open Model Thread Group?A linear rise from zero to ten arrivals per second across the minute. The rate before the span is the start rate, the rate after it is the end rate, and JMeter interpolates between them, scheduling about 300 arrivals in total.
- Which time units may a JMeter Open Model schedule use, and when may a unit be left out?ms, sec, min, hour and day, with s, m, h and d also accepted. A unit may be omitted only when the number is zero — rate(0) or random_arrivals(0) — because zero is the same in every unit. Durations may also be compound, as in 2d 1m 30s.
saying these in an interview costs you the question
- Reads the number in rate as a thread count
- Thinks the rate is applied per thread
- Assumes a missing trailing rate means a ramp down
- Says random_arrivals randomises the rate, not the instants
- Expects the schedule to be re-read during the run