What do the five Grouping options of JMeter's HTTP(S) Test Script Recorder do?

A browser click is not one request. It is a document plus twenty assets plus a couple of background calls, arriving within a few hundred milliseconds of each other. Grouping is the recorder's answer to that: it uses the *gaps between requests* to guess where one user action ended and the next began, and then lays the tree out accordingly. ## What makes a group The recorder timestamps each recorded sample and compares the gap to a threshold. A new group begins when either: - the gap since the previous recorded sample is **larger than the threshold**, or - the recorder's **Transaction name** field has changed since the previous sample — which is how the floating recorder dialog lets you name steps as you browse. The threshold comes from the `proxy.pause` property, whose default is `5000` milliseconds. The recorder's own **Create new transaction after request (ms)** field overrides it for that element when it is non-empty. The practical consequence is a discipline: while recording, pause deliberately between the actions you want to become separate steps, or rename the transaction before each one. Click straight through and everything lands in one group. ## The five options | Option | What it puts in the tree | | --- | --- | | `Do not group samplers` | Samplers appended one after another, no structure at all | | `Add separators between groups` | A Simple Controller named with a row of dashes between groups; samplers still sit flat | | `Put each group in a new controller` | A Simple Controller per group, samplers nested inside it | | `Store 1st sampler of each group only` | Only the first sampler of each group survives | | `Put each group in a new transaction controller` | A Transaction Controller per group, samplers nested inside it | The last option is the one the bundled **Recording** template selects, and it is usually what you want: each user action becomes one named Transaction Controller, so the results afterwards are per step rather than per asset. The Transaction Controllers the recorder creates are made with the "include duration of timers and pre/post processors" option switched off, and each one is named from the recorder's Transaction name field. ## The special case worth knowing `Store 1st sampler of each group only` does more than throw the other samplers away. The surviving sampler has **Follow Redirects** and **Retrieve All Embedded Resources** switched on, so at replay it re-fetches the assets it was recorded alongside instead of replaying them as literal samplers. That trades a small tidy plan for two things the plain recording did not have: the embedded-resource parsing cost moves to the injector, and the exact set of assets is no longer pinned. Those flags belong to the HTTP Request sampler, and `dev-jmeter-protocols-http-sampler` owns what they do once the plan runs. ## Things that attach only to the first sampler Grouping does not just shape the tree; it decides what else the recorder attaches. Two elements land on the sampler that *opens* a group rather than on every sampler: 1. **Add Assertions** — the blank assertion the checkbox requests; 2. any **timer placed inside the recorder element**, which is copied onto the group's first sampler with `${T}` replaced by the measured gap since the previous recorded sample. The bundled *Recording with Think Time* template uses exactly that, with a Uniform Random Timer whose delay is `${T}`. The timers themselves — what a Uniform Random Timer does at run time, where a pause takes effect — are `dev-jmeter-load-delay-timers` material; the copying is the recorder's. ## Choosing one - Recording a single short journey you will restructure by hand anyway: **Do not group samplers** keeps it honest. - Recording several journeys in one sitting and you want to see the seams: **Add separators between groups**. - Recording something you intend to report on per step: **Put each group in a new transaction controller**, and name each step in the recorder dialog before you click. - Recording a page-level plan where assets should be fetched rather than scripted: **Store 1st sampler of each group only**. Whatever you pick, the grouping is guesswork built on timing. Review the tree afterwards: a fast operator produces one enormous group, and a distracted one produces a group per request.