skip to content

Which JMeter thread group answers the criticism that its stock Thread Group cannot hold an arrival rate?

level: middleimportance: should knowfreq 44%

answer

  1. The stock group fixes users, not rate
  2. Apache added an answer in 5.5
  3. Read the component reference note carefully
  4. The bzm and jp@gc groups are installs
  5. Still labelled experimental at 6.0.0

basics

~20 s

The Open Model Thread Group, shipped in the Apache JMeter download since 5.5 and still marked experimental at 6.0.0. Third-party jmeter-plugins thread groups such as bzm - Arrivals Thread Group cover the same ground outside the Apache artifact.

solid answer

~50 s

JMeter's stock `Thread Group` is a closed model, so its `Number of Threads (users)` field caps concurrency rather than arrival rate — that is the criticism, and it is accurate. Apache's own answer is the `Open Model Thread Group`, a core component since JMeter 5.5 whose `Schedule` field describes a rate-shaped profile instead of a fixed user count. It is still labelled **experimental** in the 6.0.0 component reference, which is a fact worth stating rather than hiding when you argue the tool choice. Outside the Apache download, the jmeter-plugins Custom Thread Groups set adds `bzm - Arrivals Thread Group`, `bzm - Free-Form Arrivals Thread Group` and `bzm - Concurrency Thread Group`, among others. They are widely used and third party, so a pipeline that depends on them must install them. What an open or closed workload model actually means belongs to performance-testing fundamentals, not to JMeter.

go deeper

for a junior

Know that JMeter's stock Thread Group asks for a number of threads and a ramp-up period, and that a separate thread group exists for describing a request rate instead.

for a middle

Name the Open Model Thread Group, place it in the Apache download since 5.5, and separate it from the third-party bzm and jp@gc thread groups that need installing.

for a senior

Bring the experimental note and the 6.0.0 behaviour change into the recommendation, and say which route you would put in a pipeline and why.

for a principal

Decide how much of the team's load vocabulary should rest on an experimental core component versus a third-party dependency, and own the maintenance consequence either way.

## The criticism, stated precisely The standard complaint about Apache JMeter in a tool comparison is not that its stock thread group is bad. It is that the stock `Thread Group` is a closed model, so its `Number of Threads (users)` and `Ramp-up period (seconds)` fields let you say how many users exist and how fast they arrive, but not what request rate the system should receive. A candidate who cannot say this in one sentence loses the argument before it starts. Two clarifications keep the answer inside JMeter's own surface: - What an open or a closed workload model *is*, and why arrival rate and concurrency differ, is performance-testing theory. Name it, then move on — it is owned by the performance-workloads foundations topic, not by JMeter. - The complaint is about the *stock* thread group specifically. JMeter as a whole is not limited to it. ## What Apache ships in response Since JMeter 5.5 the Apache download has included the `Open Model Thread Group`. Its `Schedule` field expresses a load profile directly, and the component spawns threads as the profile requires rather than asking you to fix a user count up front. Two properties of it matter to a tool-choice conversation: 1. **It is core, not a plugin.** No extra install, no supply-chain question, no version to track separately. 2. **It is still experimental at 6.0.0.** JMeter's own component reference carries that note, and the component's behaviour has continued to change — JMeter 6.0.0, for example, changed the Open Model Thread Group to calculate delays relative to the start of its thread group instead of the start of the test. If you are recommending it as the answer to the criticism, say so with that caveat attached. The field-level details of its `Schedule` and `Random Seed` settings are the JMeter tree's own open-model topic; what belongs here is only which element answers the criticism and how firmly. ## The third-party route, labelled honestly | Element | Origin | |---|---| | `Thread Group` | Apache download, closed model | | `Open Model Thread Group` | Apache download since 5.5, experimental at 6.0.0 | | `bzm - Arrivals Thread Group` | third party, jmeter-plugins Custom Thread Groups | | `bzm - Free-Form Arrivals Thread Group` | third party, jmeter-plugins Custom Thread Groups | | `bzm - Concurrency Thread Group` | third party, jmeter-plugins Custom Thread Groups | | `jp@gc - Stepping Thread Group`, `jp@gc - Ultimate Thread Group` | third party, jmeter-plugins Custom Thread Groups | Many long-standing JMeter teams reach for the third-party groups first, and that is a legitimate choice — but it is a dependency your build has to install and keep current, which is a genuine input to the build-versus-adopt decision this topic exists to weigh. ## Why this matters to the tool choice - **It narrows the gap without closing it.** JMeter can express rate-shaped load, so "JMeter cannot do arrival rate" is false as stated at 6.0.0. The honest version is that JMeter's core answer is newer and still marked experimental, while the mature route is a third-party install. - **It changes what you are actually comparing.** Once the rate question is answered, the remaining axes are the plan artifact, the thread-per-user injector cost and the absent native threshold flag — not this one. - **It is a credibility test.** A candidate who says JMeter is stuck with a fixed user count is a year or more out of date; one who names the element, its version and its experimental status has actually looked. ## Where the other side is taught Nothing above describes a rival tool's vocabulary. A scripted runner's arrival-rate executors are owned by `dev-k6-executors-arrival-executors` and its scenario configuration by `dev-k6-options-scenarios-map`; the open and closed injection vocabulary of a JVM simulation DSL is owned by `dev-gatling-injection-registration`, with its individual steps under `dev-gatling-injection-per-second` and `dev-gatling-injection-held-levels`. Name them, cede them, and keep your own answer about JMeter.

  • Would you recommend the Open Model Thread Group or a third-party thread group to a team today?
    It depends on what the team can absorb. The Open Model Thread Group needs no install and is maintained with JMeter itself, but is still marked experimental and has changed behaviour between releases. The jmeter-plugins Custom Thread Groups are mature and familiar, at the price of a dependency the build must install and keep current.
  • Why is it wrong to say JMeter cannot produce rate-shaped load?
    Because the Apache download has shipped the Open Model Thread Group since 5.5, whose Schedule field describes a rate profile directly, and third-party arrival-oriented thread groups predate it. The accurate criticism is narrower: JMeter's stock Thread Group is closed, and the core alternative is newer and still flagged experimental.

saying these in an interview costs you the question

  • Claims JMeter can only fix a user count and never a rate
  • Recommends the Open Model Thread Group without mentioning its experimental note
  • Calls the bzm and jp@gc thread groups part of the Apache download
  • Confuses the stock Thread Group's ramp-up period with an arrival rate setting
  • Explains open versus closed workload theory instead of naming JMeter's elements