skip to content

How would you decide what a team's JMeter Backend Listener emits during long soak runs?

level: principalimportance: should knowfreq 36%

answer

  1. Two rows decide the whole shape
  2. Labels become series names
  3. The percentile list is a multiplier
  4. Hold the choice in properties, not plans

basics

~20 s

Start from summaryOnly and the sampler filter: they decide whether one series or one per label leaves the injector. Then settle the percentile list, the flush interval and a label naming rule, and hold all of them in properties rather than in each plan.

solid answer

~40 s

Treat the Parameters table as a contract rather than per-plan taste. `summaryOnly` is the coarse lever: `true` sends one cumulated series, `false` plus `samplersList` or `samplersRegex` sends one per matching label. Keep the filter explicit instead of leaving the InfluxDB client's shipped `.*`, so that adding a sampler cannot silently add series. Fix the `percentiles` list once, since each value becomes its own metric for each tracked label. Pick a flush interval - `backend_influxdb.send_interval` defaults to 5s, `backend_graphite.send_interval` to 1s - that matches how the run is actually watched. Standardise sampler labels, because they become the series name; for Graphite JMeter rewrites spaces to `-` and dots to `_`. What those series cost to keep, and how the dashboard is built, are observability-platform decisions rather than JMeter ones.

go deeper

for a junior

Know the two rows that matter - summaryOnly and the sampler filter - and that changing either changes how much leaves the injector during a run.

for a middle

Explain what each knob multiplies: labels times statuses times percentiles, plus a fixed set of thread metrics per run, at one point per flush interval.

for a senior

Bring the operational side. The filter must be explicit, the prefix or application row must identify the run, and the settings belong in a properties file so every environment emits the same shape.

for a principal

Own the trade honestly: say what the live stream is for, what it must carry to be worth a dependency on a metrics store, and who owns the cost of what the plans emit.

## Treat the Parameters table as a contract The Backend Listener's rows look like per-plan taste and are not. They decide, before any dashboard exists, how many distinct series a twelve-hour soak pushes and how a reader will address them next month. Settle them once, hold them in a properties file that each environment supplies, and let the `.jmx` reference them rather than hardcoding a host. The levers, in the order they matter: 1. **`summaryOnly`** - the coarse switch. `true` sends one cumulated series and ignores the sampler filter entirely. `false` is what makes any per-label detail possible. 2. **`samplersList` / `samplersRegex`** - the shape of the detail. Name the transactions you will actually look at. Leaving the InfluxDB client's shipped `.*` in place means every future sampler silently adds series without anybody deciding to. 3. **`percentiles`** - a multiplier. Each value in the semicolon-separated list becomes its own metric for each label being tracked, so a fourth percentile is not free. 4. **The flush interval** - `backend_influxdb.send_interval` (default 5s) or `backend_graphite.send_interval` (default 1s). One second of resolution is rarely what a twelve-hour soak is read at. 5. **Identity rows** - `rootMetricsPrefix` for Graphite; `application`, `measurement`, `testTitle` and any `TAG_`-prefixed custom rows for InfluxDB. These are what let you tell tonight's run from last night's. ## Sampler labels are an interface The sample label becomes the series name, which makes naming a design decision rather than a cosmetic one. For Graphite, JMeter sanitises the label first: backslash and space become `-`, and a dot becomes `_`, because Graphite treats dots as path separators. `Home Page` arrives as `Home-Page`; a percentile of `99.9` is published as `pct99_9`. Rename a sampler mid-campaign and the old series stops and a new one starts, with nothing joining them. Two rules are worth writing down for a team: labels are stable identifiers, not descriptions; and a Transaction Controller that generates a parent sample puts *its* name on the label the filter matches, not the child sampler's. ## The trade, stated honestly | If the run is... | Emit | Because | |---|---|---| | A short smoke run in CI | `summaryOnly=true` | Nobody watches it live; the result file carries the detail | | A long soak someone is watching | `summaryOnly=false` with a named filter | You need to see *which* transaction turned | | A large plan with dozens of samplers | `summaryOnly=false`, filter to the handful that matter | The rest are still in the result file | The honest limit of this decision is that only half of it is yours. JMeter decides what is emitted and how often. What those series cost to retain, how many distinct label values a metrics backend will tolerate, and how the dashboard is laid out are decisions owned by whoever runs the observability platform - and the label-cardinality bill in particular is their vocabulary, not JMeter's. The useful move at a review is to bring them the number: labels times statuses times percentiles, plus five thread metrics per run, at one point per flush interval, for however many hours the soak lasts. Agree that before the soak, not after the invoice. Finally, keep the live stream and the verdict separate. Whether a soak passed is computed from the run's own recorded results afterwards; the streamed series exist so that someone can decide, at 2 a.m., whether the run is still worth leaving running.

  • What does JMeter do to a sampler label before it becomes a Graphite metric name?
    It sanitises it: backslash and space become `-`, and a dot becomes `_`. A label like `Home Page` arrives as `Home-Page`. Percentile values go through the same rewrite, so `99.9` is published as `pct99_9`. Dots have to go because Graphite uses them as path separators.
  • Which Backend Listener metrics are sent regardless of summaryOnly and the label filter?
    The thread metrics - `minAT`, `maxAT`, `meanAT`, `startedT` and `endedT` - minimum, maximum and mean active threads plus started and finished counts. The Graphite client publishes them under a `test` context; the InfluxDB client writes them into the configured measurement tagged `transaction=internal`. The cumulated bucket goes out unconditionally too, so a run is never entirely silent.
  • Why not simply emit every sampler and decide later what to look at?
    Because the choice is one-way in the moment and expensive to unwind. Every label the plan emits becomes a series someone stores and queries, and a filter left at `.*` grows silently as the plan grows. Emitting less is a two-line change; retiring series that a dashboard already references is not.

saying these in an interview costs you the question

  • Leaves samplersRegex at .* and calls it a default
  • Adds percentiles because the graph looks nicer
  • Lets each plan choose its own metric prefix
  • Treats sampler labels as free-form descriptions
  • Assumes the metrics store absorbs any level of detail