In JMeter's Backend Listener, what does setting summaryOnly to true do to samplersList?

## The check happens in that order Inside `GraphiteBackendListenerClient.handleSampleResults` the code reads, for every result: 1. add the result to the run-wide user metrics; 2. `if (!summaryOnly)` - and only inside that branch, match the label against the filter and, on a match, feed a per-label `SamplerMetric`; 3. add the result to the cumulated bucket, unconditionally. So `summaryOnly` is not a filter of its own that stacks with `samplersList`. It is a gate in front of the filter. With `summaryOnly=true` the `samplersList` and `useRegexpForSamplersList` rows are dead configuration: they are parsed at setup and then never consulted. `InfluxdbBackendListenerClient` has the same gate, written as `if (!summaryOnly && matcher.find())`. ## The cumulated bucket is always sent Step 3 runs whatever the settings, which is why a Backend Listener never goes silent. The Graphite client publishes that bucket under the sampler name `all`, so you get `all.a.count`, `all.ok.count`, `all.ko.count`, min, max, average and the configured percentiles. The InfluxDB client writes it with `transaction=all` and `statut=all`. Alongside it go the five run-wide thread metrics - `minAT`, `maxAT`, `meanAT`, `startedT`, `endedT` - which no filter touches either; Graphite files them under a `test` context, InfluxDB under `transaction=internal`. ## The two clients spell the filter differently | | Graphite client | InfluxDB client | |---|---|---| | Filter row | `samplersList` | `samplersRegex` | | Default filter | empty | `.*` | | Interpretation | semicolon-separated exact labels, or one regex when `useRegexpForSamplersList=true` | always a regex | | Match style | set membership, or a whole-string regex match | regex substring search | | Shipped `summaryOnly` | `true` | `false` | Two consequences follow from that last row. Drop a Backend Listener on a plan, choose the Graphite client, list four samplers and you will see nothing but `all` until you also set `summaryOnly=false`. Choose the InfluxDB client and leave the table alone and you get the opposite surprise: a series per transaction from the very first flush, because `summaryOnly=false` and `samplersRegex=.*` are both already there. (The component reference's parameter table still describes the InfluxDB client's `summaryOnly` as defaulting to `true`; the shipped default arguments and the setup code both use `false`.) ## Getting the match right The Graphite client's regex mode uses a **whole-string** match: `Checkout` will not match the label `Checkout page`. The InfluxDB client uses a **substring** search, so `Checkout` does match `Checkout page` - and `.` matches anything, so a careless regex quietly widens the filter. In list mode the labels are split on `;` and compared exactly, including any leading or trailing spaces you typed into the field. Two practical habits follow: - **Name the filter explicitly** rather than relying on `.*`, so that adding a sampler to the plan is a deliberate decision about what gets streamed rather than an accident. - **Check the label, not the element name you think you used.** The filter matches the sample label, which for a Transaction Controller with a generated parent sample is the controller's name, not the child sampler's. What those extra per-label series cost to store, index and query is a question for whoever runs the metrics platform, not for the test plan; the plan's job is to make the choice explicit.