skip to content

How would you decide which browser-like state a JMeter plan keeps between thread iterations?

level: principalimportance: should knowfreq 33%

answer

  1. More than one switch, no master control
  2. Each element clears itself
  3. One of them holds nothing at all
  4. Defaults all lean towards keeping

basics

~20 s

JMeter has no single reset: the Cookie, Cache, DNS Cache and Authorization Managers each carry their own per-iteration clearing option. Name the population you are simulating, then set all four deliberately in a plan template.

solid answer

~50 s

JMeter does not have one "reset the virtual user" control. Four config elements each hold per-thread state and each exposes its own clearing option: **Clear cookies each iteration**, **Clear cache each iteration** on both the HTTP Cache Manager and the DNS Cache Manager, and **Clear auth on each iteration** — which in practice clears cached Kerberos subjects only. Three of them additionally offer *Use Thread Group configuration to control ... clearing*, deferring the decision to the Thread Group. The HTTP Header Manager is the odd one out: it holds no per-thread state, it merges a fixed list of headers. Leaving these at mixed defaults gives you a run whose second iteration is quietly cheaper than its first in three separate ways, and nobody can say which. The judgment call is which posture the plan is meant to describe, and then enforcing it as a template rather than a habit.

go deeper

for a junior

Recall that JMeter clears state per element, not per plan, and that each of these config elements has its own checkbox.

for a middle

Explain what each element actually holds and what its clearing option resets it to at the iteration boundary.

for a senior

Audit an inherited plan against all four switches and spot the ones whose effect on sample counts is invisible.

for a principal

Set the team standard: one declared posture, expressed in a plan template and a shared properties file, with exceptions that carry a reason.

## The four switches, and the one element that has none | Element | Per-thread state it holds | Its clearing control | |---|---|---| | HTTP Cookie Manager | The thread's cookie store | `Clear cookies each iteration` — resets to the hand-typed rows only | | HTTP Cache Manager | Up to `maxSize` cached entries, default 5000 | `Clear cache each iteration` | | DNS Cache Manager | Resolved hostname to address map | `Clear cache each iteration` | | HTTP Authorization Manager | Cached Kerberos subjects | `Clear auth on each iteration` — Kerberos only | | HTTP Header Manager | **None** | n/a — it merges a fixed header list | The Cookie, Cache and Authorization managers each also offer *Use Thread Group configuration to control ... clearing*, which hands the decision to the Thread Group instead of the element's own checkbox. That is a fifth place a reader has to look before they can tell you what a plan does. ## Why this is a decision and not a default With everything left alone, the second iteration through a Thread Group is a returning visitor: it already has a session cookie, it already has the static assets cached — and by default those cache hits produce **no sample at all**, so the sample count drops as well as the times — and it already knows the backend's address. Iteration one paid for all of it. That can be exactly right. Most real traffic is returning traffic. But it is a claim about the population you are simulating, and if it is never written down, two engineers running "the same plan" a month apart will produce different shapes of traffic and argue about the numbers. How to reason about which population is correct, and what the difference does to a capacity figure, belongs to the performance-testing foundations material rather than to JMeter. What JMeter owns — and what you own as the person setting the standard — is that the switches exist, that they default to *keep*, and that a plan can state its choice explicitly instead of inheriting it. ## How I would decide 1. **Name the population first.** First-time visitor, returning visitor, or a mix. That single sentence fixes all four switches, and it goes in the plan's own comment field where the next reader will find it. 2. **Make the cache posture visible whichever way you choose.** If the cache is kept, set `cache_manager.cached_resource_mode=RETURN_200_CACHE` so hits appear as rows rather than as an unexplained fall in sample count. A silently shrinking sample count is the single most expensive artefact in this family. 3. **Do not use the Cookie Manager's clearing switch to fake a mix.** Clearing per iteration gives every iteration a fresh session; it does not give you 30% new users. A mix is a Thread Group and plan-structure question, not a checkbox. 4. **Treat the DNS switch separately from the other two.** Its consequence is which machine you measured, not how fast the client was. On a load-balanced target it deserves a deliberate answer even when the cookie and cache answers are obvious. 5. **Standardise, then allow exceptions with a reason.** A template plan with all four elements present and all switches set beats forty plans that each inherited a default. ## What to check when you inherit a plan - Does a Cache Manager exist, and is `Use Cache-Control/Expires header when processing GET requests` on? A plan added through the GUI has it on and clearing off. - Are there two Cookie Managers in one scope? There is no way to say which wins, and cookies do not cross between them. - Are the samplers on HttpClient4? If not, the DNS Cache Manager is inert and nobody was told. - Is `Clear auth on each iteration` ticked on a plan that uses BASIC? It will do nothing; it clears Kerberos subjects. - Does the plan depend on `bin/user.properties` keys such as `CookieManager.save.cookies` or `cache_manager.cached_resource_mode`? Those travel with the injector, not with the `.jmx`, and are the classic reason a plan behaves differently on someone else's machine. ## The honest summary There is no universally correct posture. There is a correct *practice*: pick one, express it in the plan rather than in the defaults, make the cache's effect on sample counts visible, and re-check the four switches whenever a plan changes hands.

  • Which of these JMeter elements holds no per-thread state at all?
    The HTTP Header Manager. It merges a fixed list of headers into the request and has nothing to clear, which is why it has no per-iteration option. Everything it contributes is identical on iteration one and iteration fifty.
  • A JMeter plan ticks Clear auth on each iteration but authenticates with BASIC. What changes?
    Nothing observable. That option clears cached Kerberos subjects so Kerberos authentication is redone each iteration; BASIC and DIGEST entries in the Authorization Manager are unaffected and are matched per request anyway.
  • Where would you record a JMeter plan's chosen state posture so the next person finds it?
    In the plan itself — the Test Plan comment field and the element names — plus the shared `bin/user.properties` for anything property-driven. Property-driven settings do not travel inside the `.jmx`, so a plan that depends on them has to say so.

saying these in an interview costs you the question

  • Assumes one master switch resets the whole virtual user
  • Says the Header Manager needs clearing between iterations
  • Thinks clearing cookies each iteration models a user mix
  • Leaves the four switches at whatever the defaults were
  • Forgets that property-driven settings do not travel in the .jmx