What Correlation Means in Load Testing
Correlation is the process of capturing a dynamic value returned by the server, such as a session ID, CSRF token, order confirmation number, or authentication token, and feeding it into subsequent requests that require it. When a script is recorded with JMeter's HTTP(S) Test Script Recorder, these dynamic values get captured as hardcoded strings from that one recording session; replaying the script later fails, because the server issues a fresh value on every real run and rejects the stale recorded one. Correlation fixes this by inserting an extractor after the response that generates the value, storing it in a JMeter variable, and referencing that variable, not a literal, in every later sampler that needs it.
Cricket analogy: An uncorrelated recorded token is like writing down today's toss result and assuming it applies to tomorrow's match too, the server issues a fresh 'toss' every time, so replaying yesterday's captured value gets you rejected at the gate.
Regular Expression Extractor
Reference Name: authToken
Regular Expression: "token":"(.*?)"
Template: $1$
Match No.: 1
Default Value: TOKEN_NOT_FOUNDThe Regular Expression Extractor is added as a Post-Processor beneath the sampler whose response contains the value you need. Its 'Regular Expression' field uses a capture group, like "token":"(.*?)" to match a JSON token field, and the Template field, typically $1$, selects which capture group becomes the variable's value. 'Match No.' controls which occurrence to use when a pattern matches multiple times in the response (0 picks a random match, -1 combined with special handling captures all matches into an indexed variable, and a positive number picks that specific occurrence), and 'Apply to' lets you extract from the response body, headers, or even the request itself rather than only the main sample result.
Cricket analogy: Match No. selecting a specific occurrence is like a commentator picking out the third boundary of the over specifically from a highlights reel that shows every shot, you need to specify which exact instance you want.
JSON Extractor and XPath/CSS Extractors
For JSON APIs, the JSON Extractor is generally more robust than a regex because it uses JsonPath expressions like $.data.token to navigate the parsed JSON structure directly, so it keeps working even if the server changes whitespace, key order, or formatting in a way that would silently break a regex pattern tuned to exact spacing. For HTML pages, the CSS/JQuery Extractor selects elements using familiar CSS selectors like input[name='csrf_token'] and an attribute name, while the XPath Extractor is suited to XML or SOAP responses, navigating with XPath expressions like a document tree. All three extractor types share the same core fields: Reference Name, the expression, Match No., and Default Value.
Cricket analogy: A JsonPath expression navigating nested JSON is like a scorecard app drilling directly into 'innings 2 > batsman 4 > runs' by structured path rather than scanning the whole page of text hoping to spot the right number.
Prefer the JSON Extractor over the Regular Expression Extractor whenever the response is JSON; JsonPath expressions are far less brittle to formatting changes than hand-tuned regex patterns.
Debugging Correlation with the Debug Sampler
Correlation bugs are notoriously hard to spot from response codes alone, since a missing or wrong extracted value often produces a valid-looking but functionally incorrect request. Adding a Debug Sampler (which reports all current JMeter variables and properties) followed by a View Results Tree listener lets you inspect exactly what an extractor captured for a given thread and iteration. Setting a distinctive Default Value, such as TOKEN_NOT_FOUND, on every extractor is a deliberate debugging technique: if that literal string ever shows up in a later request's body or a failed assertion, it immediately signals that the extraction failed rather than silently sending an empty or stale value.
Cricket analogy: A distinctive Default Value like TOKEN_NOT_FOUND is like a scorer marking an entry as 'DNB' (did not bat) rather than leaving the cell blank, an unmistakable signal that something specific didn't happen as expected.
Debug Sampler and View Results Tree add significant memory and I/O overhead by capturing every response; always disable or remove them before running the actual load test, keeping them only for functional debugging runs with a small number of threads.
- Correlation captures dynamic server-generated values (tokens, IDs) and replays them via variables instead of stale hardcoded recorded values.
- The Regular Expression Extractor uses a capture group, Template, Match No., and Default Value to pull a value from a response.
- The JSON Extractor uses JsonPath and is more robust than regex for JSON APIs since it tolerates formatting changes.
- CSS/JQuery Extractor suits HTML responses; XPath Extractor suits XML/SOAP responses.
- Setting a distinctive Default Value (e.g., TOKEN_NOT_FOUND) makes failed extractions immediately visible downstream.
- Debug Sampler plus View Results Tree is the standard way to inspect what an extractor actually captured.
- Debug listeners should be disabled before running real load tests due to their memory and I/O overhead.
Practice what you learned
1. Why does a script recorded once and replayed later often fail on requests involving session tokens?
2. In the Regular Expression Extractor, what does the Template field '$1$' refer to?
3. Why is the JSON Extractor generally preferred over the Regular Expression Extractor for JSON API responses?
4. What is the purpose of setting a distinctive Default Value like 'TOKEN_NOT_FOUND' on an extractor?
5. Why should Debug Sampler and View Results Tree be removed before running an actual load test?
Was this page helpful?
You May Also Like
HTTP Request Sampler
The core JMeter element for sending HTTP/HTTPS requests to a server, covering method, path, parameters, body data, and implementation settings.
Configuring Headers and Cookies
Use the HTTP Header Manager and HTTP Cookie Manager to simulate realistic browser and API-client behavior, including auth headers and session cookies.
Parameterizing Requests with CSV Data
Use the CSV Data Set Config element to drive requests with varied, realistic test data instead of hardcoded values, avoiding caching and duplicate-key artifacts.