skip to content

Across a team's JMeter plans, how would you decide what a load run may record and keep?

level: principalimportance: should knowfreq 38%

answer

  1. Argue about the default, not each plan
  2. Evidence bought with injector capacity
  3. Exceptions need an owner and an end
  4. Disabled elements cost nothing at run time

basics

~20 s

Set a default the injector can always afford - a lean writer, errors only, nothing retained - and make richer recording an explicit, time-boxed exception that someone owns rather than a habit plans drift into.

solid answer

~50 s

Treat it as a default plus an exception process, not a rule per plan. The default worth defending: no listener that retains samples in a load plan, at most one lean writer, *Log/Display Only: Errors* on anything that must stay, and a **Save Responses to a file** listener with **Save Failed Responses only** when bodies are genuinely needed as evidence. Debugging elements can live in the file **disabled** - disabled elements are dropped before any thread starts, so they cost nothing at run time and are still there when you next open the plan. Then name who may deviate, for which question, at what scope, and for how long. The failure this prevents is drift: each addition was reasonable, and the aggregate is a generator that cannot reach the load the plan asks for while still producing plausible numbers.

go deeper

for a junior

Follow the convention rather than inventing one: leave the retaining listeners out of a run that is meant to measure something, and ask before adding one back.

for a middle

Be able to implement the policy - a lean writer, errors-only filtering, failed-response saving - and explain to a colleague why each choice is cheaper than the obvious alternative.

for a senior

Spot the drift in review, and know the diagnostic loop: reduce load and record richly to answer a question, then put the plan back to its default before the next real run.

for a principal

Own the default, the exception process and the honesty about what the policy costs when a run fails, and make sure the same budget conversation covers the result file and the verification the plan performs.

## The tradeoff you are actually setting Every recording choice in a JMeter plan buys evidence with injector capacity. Retaining sample results in a listener buys the ability to click a failure and read its response; it is paid for in heap and in work done on the sampling threads, at exactly the moment the run is supposed to be measuring something else. The policy question is not *"is recording good?"* — it is *what is the default, who may deviate from it, and how does a deviation get switched back off?* The failure mode this policy exists to prevent is not one dramatic plan. It is drift: a listener added during scripting and never removed, a second one added by the next person for the same reason, and a result file that grew columns nobody reads. Each addition was reasonable; the aggregate is a generator that cannot reach the load the plan asks for, and — worse — nobody notices, because the run still produces numbers. ## A default worth defending - **No listener retains samples in a load plan.** View Results Tree and View Results in Table are scripting tools. This is the manual's own advice, not a house preference. - **One lean writer, if any.** A Simple Data Writer discards each result once its record is written; its own documentation describes it as eliminating the GUI overhead. Which columns it writes is the result-file topic's business, but *whether the plan writes a wide record at all* is a cost decision, and narrow wins. - **Errors only, where a listener must stay.** The *Log/Display Only: Errors* checkbox filters before both the display and the write, so successful samples cost nothing. - **Evidence by exception, not by default.** A *Save Responses to a file* listener with **Save Failed Responses only** ticked gives you the bodies of exactly the samples you will want to look at, and nothing else. - **Disabled beats deleted during authoring, and both beat left-on.** Disabled elements are dropped from the plan before any thread starts, so the debugging kit can live in the file without costing a run. ## Where the exceptions go Some runs genuinely need more. Make that a decision with an owner and an end date rather than a default: 1. **Name the question.** "We cannot reproduce the 500s" is a reason to record more; "it might be useful" is not. 2. **Scope it.** Turn the extra recording on for the one sampler or one thread group that is under suspicion, not for the plan. 3. **Reduce the load, not the fidelity.** A twenty-thread diagnostic run with everything recorded usually answers the question faster than a full-load run with a heavier plan and a distorted result. 4. **Put it back.** The exception should be visible in review — which is easier if the plan lives in version control and the diff shows a listener being enabled. ## Separating the debug plan from the load plan The cleanest arrangement most teams land on is two configurations of the same plan rather than two plans: the elements that are only for debugging exist, disabled, in the file, and the run that matters never enables them. Two genuinely separate files drift apart, and the drift is discovered at the worst moment. Whichever mechanism you choose, the property to preserve is that *the plan you load to debug and the plan you run under load are the same plan*, because a bug that only appears at 500 threads is not going to reproduce in the other one. ## What you cannot buy back later Be honest about what the policy costs. A lean run that fails gives you counts, timings and error codes, and not the response that caused them; you get those back by re-running with recording turned up, which costs a slot in the schedule. That is usually the right trade — but it is a trade, and the team should make it knowingly rather than discovering it at 2am. State it in the plan's own documentation: *this run records X; if it fails in way Y, re-run with Z.* The related decisions sit in neighbouring topics and are worth settling at the same time: what the result file's columns should be, how much verification runs on the sampler thread, and what the report you generate afterwards is actually read for.

  • What does a lean-by-default policy cost you the first time a run fails?
    The responses. You keep counts, timings and error codes, but not the bodies that would explain them, so the answer is a re-run with recording turned up - which costs a slot in the schedule. That is usually the right trade, but it should be stated in the plan's own notes so nobody discovers it during an incident.
  • How do you stop the debugging plan and the load plan from drifting apart?
    Keep them as one plan with the debugging elements present but disabled, rather than two files. Disabled elements are removed before the run, so they cost nothing, and the plan you debug is provably the plan you ran. Two separate files diverge quietly, and the divergence is discovered when a failure only reproduces in the one you are not holding.
  • Which neighbouring decisions should be settled at the same time as this one?
    What the result file's columns should be, how much verification runs on the sampling thread, and what the generated report is actually read for. Each is owned by its own topic, but they compete for the same injector budget, so deciding recording policy without them tends to produce a lean writer emitting a very wide record.

saying these in an interview costs you the question

  • Argues each plan separately instead of setting a default
  • Records everything in case it is useful later
  • Treats retained listeners as free once the run is unattended
  • Never revisits an exception once it is granted
  • Keeps two divergent copies of the same plan