skip to content

How would you decide whether a team's JMeter plans may depend on the Custom Thread Groups add-on?

level: principalimportance: should knowfreq 31%

answer

  1. The plan file names the class itself
  2. Ask what core elements cannot say
  3. Count the machines that open plans
  4. Newest is not the same as pinned

basics

~20 s

Weigh what the add-on expresses that stock elements cannot against the cost: every machine that opens or runs a plan needs the same pinned jar, and without it the plan will not load at all.

solid answer

~50 s

Treat it as a coupling decision rather than a feature question. On the credit side, `jpgc-casutg` is the only way to write an equal-landing staircase (`Ramp-Up Steps Count`), an arbitrary set of overlapping blocks (the Ultimate Thread Group's schedule table or its `threads_schedule` property), or a group that creates threads lazily instead of up front. On the debit side, the `.jmx` stores these elements by class name, so a missing jar is a plan that cannot be opened, not a run that degrades; the jar must be present and **pinned to the same version** on every authoring desktop, every injector and every build image; and the add-on releases on its own cadence, so a JMeter upgrade becomes two upgrades. Decide it once, for the whole team, and write down the version. If the profile you actually need can be said with core elements, say it with core elements.

go deeper

for a junior

Know that these thread groups come from an add-on, and that adding one to a plan makes that jar a requirement for everybody who opens the file.

for a middle

Explain the mechanism behind the coupling: the element is stored by class name, so the dependency is on the classpath of every machine, and it fails at load time.

for a senior

Show how you would roll it out and verify it - pinned version, an inventory taken from the plans themselves, and a check that runs before a scheduled run rather than after.

for a principal

Own the call itself: state what the add-on expresses that core JMeter cannot, what coupling that puts into the plan files, and why your team's answer is yes or no - then commit to keeping one version everywhere.

## Frame it as coupling, not as a feature The question is not *are these elements good* - they are, and they are widely used. It is *what does a plan file become once it names a class that Apache does not ship*. Because a `.jmx` records third-party elements under their fully-qualified class names, the dependency is hard: a machine without the jar cannot open the plan, review it, or run it. That is a stronger commitment than most tool add-ons ask for, and it is the fact the decision should turn on. ## What you are buying The **Custom Thread Groups** add-on (`jpgc-casutg`) gives you three things core JMeter has no field for: - **An equal-landing staircase.** The Concurrency Thread Group's `Ramp-Up Steps Count` divides `Target Concurrency` and `Ramp Up Time` into equal landings. No stock element has a step field. - **An arbitrary block schedule.** The Ultimate Thread Group's five-column table - and its `threads_schedule` property - lets each block carry its own delay, startup, hold and shutdown. - **Lazy thread creation.** The Concurrency and Arrivals groups start threads from a background starter as the level demands them, instead of constructing the full count when the group starts. ## What you are paying | Cost | What it means in practice | |---|---| | Plan portability | a plan that names the class will not open without the jar, anywhere | | Fleet uniformity | every desktop, injector and build image needs the same jar | | Version drift | `install jpgc-casutg` takes the newest; only `install jpgc-casutg=3.1.1` pins one | | Upgrade surface | the add-on and Apache JMeter release independently | | Exit cost | moving off it later is a plan-wide edit, because the element is the class name | ## The alternatives worth pricing first Before adopting, ask whether the profile genuinely needs the add-on: 1. **Core elements you already have.** JMeter 6 ships the Open Model Thread Group and the ordinary Thread Group; several stock groups with staggered starts can approximate a staircase, at the cost of a busier plan. Those elements' own fields are a separate subject - the point here is only that they exist and cost nothing to distribute. 2. **A different profile.** Sometimes the staircase is an authoring habit rather than a requirement, and a shape the stock elements can express is acceptable. What each run shape is *for* is not a JMeter question and is decided elsewhere. 3. **A different tool entirely.** If your profiles keep outgrowing what the plan format can say, that is an argument about tooling, not about this jar. ## If you adopt it, adopt it properly A yes is only safe with the mechanics attached: - **Pin the version** in whatever provisions your JMeter installs, using the `id=version` form; record it beside the plans. - **Inventory the dependency from the plans themselves**, by grepping for `kg.apc` and `com.blazemeter`, so the list cannot drift away from what the files actually need. - **Make the check early and loud.** `PluginsManagerCMD status` on a machine, or `install-for-jmx` against the plan, both answer the question before a scheduled run discovers it. - **Decide once, for everyone.** The worst outcome is a mixed estate where some plans need the jar and some do not, because then every machine is a special case. ## The answer an interviewer wants There is no single right verdict, and saying *always use it* or *never use it* both miss. What a lead is expected to own is the reasoning: name what the add-on expresses that core JMeter cannot, name the coupling it creates in the plan file, and say which of those matters more for the team's plans, injectors and review habits - and then say how the version is kept the same everywhere once the answer is yes.

  • What makes a JMeter plugin dependency harder to live with than a library dependency in application code?
    There is no build step to resolve it. The plan is data, not code, and it names the class directly, so the dependency is only satisfied by a jar that someone has already placed on the classpath of the machine opening the file. Nothing declares it, and nothing fails at build time.
  • How would you pin the Custom Thread Groups add-on to one version across a fleet of JMeter machines?
    Provision the jar the same way you provision JMeter itself, and use the Plugins Manager's `id=version` form - `PluginsManagerCMD install jpgc-casutg=3.1.1` - rather than the bare id, which installs the newest available. Record that version next to the plans so a mismatch is visible.
  • If you decide against the add-on, what do you lose that JMeter 6 cannot replace?
    The equal-landing staircase field, the Ultimate Thread Group's arbitrary block table, and lazy thread creation. Core JMeter 6 has the Thread Group and the Open Model Thread Group, so a stepped concurrency profile has to be approximated by composing stock groups instead of typing a step count.

saying these in an interview costs you the question

  • Calls the add-on part of JMeter and stops there
  • Installs the newest version rather than a pinned one
  • Assumes only the injector needs the jar
  • Treats a missing plugin as a degraded run
  • Adopts it without inventorying which plans need it