What does JMeter's Thread Group checkbox 'Same user on each iteration' change between iterations?

## What the checkbox is `Same user on each iteration` sits in the Thread Group's `Thread Properties` box, just under `Loop Count`. In a saved plan it is the boolean `ThreadGroup.same_user_on_next_iteration`, and its schema default in JMeter 6.0.0 is **true** — a new Thread Group is created with it ticked. It is a declaration about the meaning of an iteration boundary, not an action: the Thread Group publishes the value on each of its threads and other elements decide what to do with it. ## Who actually reads it Three HTTP configuration elements and the HTTP client itself: - the **HTTP Cookie Manager** re-initialises its cookie store at the start of an iteration when the box is cleared; - the **HTTP Cache Manager** clears its cache under the same condition; - the **HTTP Authorization Manager** discards its cached Kerberos subjects the same way; - the HTTP sampler implementation resets connection and TLS state, honouring the `httpclient.reset_state_on_thread_group_iteration` property only when the box is cleared. With the box ticked, JMeter logs that the group is configured to simulate a returning visitor and ignores that property. The three managers each have their own per-element setting for whether they follow the thread group or their own per-iteration switch, so the Thread Group checkbox governs them only when they are set to be controlled by the thread group. Those element-level options belong to the managers, not to this panel. ## Ticked versus cleared | | ticked (default) | cleared | |---|---|---| | cookies across iterations | kept | dropped | | cached entries | kept | cleared | | connection and TLS state | reused | new connection, TLS renegotiated | | what an iteration models | one returning visitor looping | a fresh visitor each time | | per-iteration cost | lower | higher connect and handshake time | ## Why it changes your numbers On a 200-thread group looping for a fixed hour, the choice shows up twice. First in the results: with the box cleared, every iteration pays a fresh connection and TLS handshake, so the first sampler of each iteration is measurably slower and the mix of recorded times shifts. Second on the generator: cleared means far more connection churn per thread over an hour of looping, which is work the injector does on top of the plan. The manual states both effects plainly — a new connection between iterations, increased response times, more memory and CPU. It also changes what the plan *means*. A login-then-browse plan looping with the box ticked is one signed-in user repeating an activity; the same plan with the box cleared is a stream of new arrivals, each of which must authenticate again. Neither is wrong, but only one of them matches any given scenario, and the checkbox is where that intent is recorded. ## Reading it in an unfamiliar plan 1. Open the Thread Group and note the checkbox state. 2. Check whether the plan even has a Cookie or Cache Manager in scope — with neither, clearing the box still affects connection reuse but changes no stored state. 3. Check the managers' own controlled-by-thread-group setting, since that decides whether they follow the Thread Group at all. 4. Compare against the intended scenario: returning visitor, or new visitor each iteration. ## Common mistakes - Assuming the default is "new user each iteration" — it is the opposite. - Expecting the checkbox to reset JMeter variables or CSV positions; it governs HTTP-side per-user state, not the thread's variables. - Clearing it "to be safe" on a long looping run and then puzzling over slower first samplers and higher generator load. - Believing it needs no managers to have any effect, or conversely that it does nothing without them; connection and TLS reset happen either way.