Pre-Processors, Post-Processors, Extractors, and Correlation: Configuration, Design Patterns, and Trade-Offs

1. Correlation flexibility does not weaken target controls

2. Extract from body, header, or cookie?

3. Dedicated extractor versus JSR223

Use a built-in extractor when it can state the contract directly. JSR223/Groovy becomes justified for cross-field transformation, cryptographic signing in an authorized synthetic test, custom binary parsing, or logic not expressible with built-ins.

When scripting, use vars.get()/vars.put() for per-thread data and cache compiled Groovy scripts. Avoid BeanShell for new high-throughput logic when Groovy/JSR223 is available.

4. Local variable versus global property

5. Fail immediately or silently default?

An extractor default such as CORR_MISSING is useful for diagnostics because it tells you the extractor ran and found no match. It should not become a value that the test quietly sends for thousands of requests.

A strong pattern is:

1. extract with an explicit sentinel during development;
2. assert the producer sample created a non-sentinel value;
3. choose a thread error action that skips/stops dependent work if correlation is mandatory;
4. preserve the first failure before retrying.

6. Beware stale variables when no default is configured

Some extractors can leave an existing variable unchanged when no match occurs if no default is supplied. That can be intentional when several elements conditionally populate the same variable, but it is dangerous for ordinary session correlation: iteration 2 may reuse iteration 1's token after the producer response changed.

For mandatory session correlation, clear/set a sentinel before extraction or use an extractor default and assert it.

7. Narrow versus broad processor scope

A processor under Start Session is causally obvious. The same processor under Thread Group may run for every sampler and overwrite the variable on responses that do not contain the field. Broad scope is appropriate only when all in-scope responses share the same extraction/preparation contract.

8. PreProcessor scope can also surprise you

A JSR223 PreProcessor under Thread Group runs before each descendant sampler. If it mutates PREPARED_TOKEN, that mutation occurs even before Start Session—before a token exists. Attach it to Use Session if only that request needs the transformation.

9. Main samples and sub-samples are separate populations

Extractors have Apply-to controls because HTTP embedded resources and some controllers can produce sub-samples. Select Main sample only when the token lives in the primary JSON response. Searching main + sub-samples can pick the wrong match when the same marker appears in assets/redirects.

10. Correlation data is often sensitive

Real correlation variables may be bearer credentials, CSRF tokens, account IDs, payment IDs, or signed URLs. Avoid Debug Sampler/property dumps, JTL sample-variable capture, response-body retention, and log.info(token) in load mode. Prefer redacted fingerprints and synthetic data.

11. Correlation has generator cost

Parsing a small JSON field is usually cheap. Repeated full-document XPath, body-unescaping, large-document extraction, or custom scripts can become injector work. If adding correlation reduces achieved rate, compare generator CPU/GC, sample throughput, and target service time before blaming the SUT.

12. Keep correlation separate from surrounding configuration layers

13. Worked scenario: JSON token then signed request

Suppose Login returns JSON token auth.token, and Submit requires a derived signature. Preferred design:

1. JSON JMESPath Extractor under Login creates AUTH_TOKEN.
2. Assertion under Login rejects AUTH_TOKEN=AUTH_MISSING.
3. Cached Groovy PreProcessor under Submit derives signature into SIGNATURE if built-in functions cannot.
4. Submit reads ${AUTH_TOKEN} / ${SIGNATURE}.
5. Neither value is copied to props or logged.

14. Decision table

15. Preserve correlation evidence without preserving secrets

For meaningful load runs, preserve JTL plus matching jmeter.log, JMX/extractor settings, synthetic or redacted target event evidence, and generator observations. The JTL tells you which sampler failed; jmeter.log shows engine/script/extractor diagnostics; target logs confirm the request actually carried a valid session mapping.

Knowledge check

Official references and version notes

• Elements of a Test Plan — Pre-Processor/Post-Processor purpose, scope, and execution order: configuration → pre-processors → timers → sampler → post-processors → assertions → listeners.
• Component Reference — Regular Expression, JSON/JMESPath, Boundary, JSR223 Pre/Post Processor, User Parameters, and Result Status Action Handler semantics.
• Functions and Variables — thread-local JMeter variables versus process-wide JMeter properties.
• Best Practices — CLI load execution and scripting/performance guidance.
• Apache JMeter downloads — current stable release and Java requirement.