skip to content

In JMeter, does a Pre-Processor scoped to a sampler run before or after that sampler's timers?

level: middleimportance: nice to knowfreq 26%

answer

  1. Two things happen before the request
  2. One of them sleeps, one computes
  3. The manual numbers them 1 and 2
  4. Freshness is the thing that suffers

basics

~10 s

Before. JMeter runs every Pre-Processor in scope, then serves the timers, then invokes the sampler. Anything a Pre-Processor computes is already as old as the pause when the request finally leaves.

solid answer

~40 s

Pre-Processors come first. The manual's execution order lists Pre-Processors at step 1 and Timers at step 2, and `JMeterThread.executeSamplePackage(...)` calls `runPreProcessors(...)` and only afterwards `delay(pack.getTimers())`. The sampler is invoked after both. The practical consequence is staleness: a JSR223 PreProcessor that mints a timestamp, signature, nonce or idempotency key does so *before* the wait, so with a 10-second timer in scope the value arrives at the server ten seconds old. Short-lived credentials fail for reasons that look nothing like an ordering problem. If a value must be fresh at send time, either put the pause on the previous sampler or resolve the value in the sampler's own field with a function rather than in a Pre-Processor.

go deeper

for a junior

Recall that both a Pre-Processor and a Timer run before the request, and that the Pre-Processor is the earlier of the two.

for a middle

Explain the engine calls in order and name the staleness consequence: a computed value ages by the full pause before it is sent.

for a senior

Recognise this shape when short-lived credentials fail only in plans with long pauses, and restructure the plan rather than reaching for a setting.

for a principal

Decide where time-sensitive computation belongs across a team's plans, so that adding a pause somewhere cannot silently invalidate a signature elsewhere.

## The answer, and where it is written Pre-Processors run **before** the timers. The manual's numbered execution order puts Pre-Processors at step 1 and Timers at step 2, and `JMeterThread.executeSamplePackage(...)` calls `runPreProcessors(pack.getPreProcessors())` and only then `delay(pack.getTimers())`. The sampler is invoked after both. So one sampler's turn opens like this: 1. Config elements are merged into the sampler. 2. Every Pre-Processor in scope runs, in scope-then-tree order. 3. Every Timer in scope is consulted and the thread waits before anything is sent. 4. The sampler is invoked. ## Why the ordering is easy to get backwards Two intuitions push the wrong way. The first is that a timer looks like a *gap between* requests, so it feels as though it belongs to the end of the previous sampler's turn; it does not — JMeter serves it at the head of the *next* sampler's turn. The second is that a Pre-Processor is described as running "just prior to that sampler element running", which people read as *immediately* prior, with nothing in between. The timer is in between. ## The consequence that actually bites Anything a Pre-Processor computes is already as old as the timer's sleep by the time the request leaves. That matters whenever the computed value is time-sensitive: - a request signature or HMAC built over a timestamp with a short validity window; - a nonce or idempotency key checked against a server-side expiry; - a value read out of a shared store that another thread can overwrite during the pause; - a `Date` or epoch field that a downstream assertion later compares against "now". With a Constant Timer of 10000 ms in scope, a signature minted in a JSR223 PreProcessor is ten seconds stale on arrival. Nothing warns you: the sampler simply comes back with an authentication error, and the plan looks correct on the screen. ## How to work around it The fix is to move the time-sensitive computation to somewhere that runs after the wait. Two options, both plain plan restructuring rather than a setting: - Put the pause on the **previous** sampler instead, so the wait has already happened when this sampler's Pre-Processor runs. - Compute the value in a JMeter function evaluated in the sampler's own field, rather than in a Pre-Processor, so it is resolved when the sampler is configured for sending. ## What this is not This is a question about *ordering inside one sampler's turn*. How long to pause, what shape the pauses should have, and how many timers stack when several are in scope are separate matters owned by other parts of the plan-composition material. The only claim here is positional: Pre-Processor, then Timer, then Sampler — in Apache JMeter 6.0.0 and in every 5.x before it.

  • If the Pre-Processor must produce a value that is fresh at send time, what do you change?
    Move the wait rather than the processor. Put the pause on the preceding sampler so it has already elapsed, or resolve the value in the sampler's own field using a JMeter function, which is evaluated when the sampler is configured for sending rather than at step 1.

saying these in an interview costs you the question

  • Says timers are always served first, before any processor
  • Assumes a Pre-Processor runs immediately before the request with nothing between
  • Thinks a Pre-Processor re-runs after the timer expires
  • Says the two are ordered by their position in the tree