In JMeter, does one JSON Extractor with three expressions parse the response body only once?

Assumed version: Apache JMeter 6.0.0. ## What the element does per sample When a sampler in its scope finishes, the JSON Extractor does roughly this: 1. Collect the response bodies its **Apply to** setting selects, as strings. 2. Split its four semicolon-separated fields into aligned lists. 3. **For each expression in the list**, hand the response string plus that expression to the JSON reader and collect the results. 4. Write the variables for that expression, then move to the next one. Step 3 is the point. The reader is given a *string*, not a document object it built earlier, so it starts from the first character every time. Three expressions against one confirmation body is three full parses of that body, in that thread, for that sample. ## What JMeter actually caches Every structure-aware extractor in the family caches something, and with one exception it is always the compiled expression: | Element | Cache | Sizing property | Default | |---|---|---|---| | JSON Extractor | per-thread map of expression to compiled query | none — the map is unbounded but tiny in practice | — | | JSON JMESPath Extractor | shared compiled-expression cache | `jmespath.parser.cache.size` | 400 | | XPath2 Extractor | compiled-query cache keyed on query and namespaces | `xpath2query.parser.cache.size` | 400 | | CSS Selector Extractor | compiled-selector cache, **Jodd implementation only** | `cssselector.parser.cache.size` | 400 | Two details are easy to get wrong. First, `jmespath.parser.cache.size` is not shipped as a commented line in `jmeter.properties` the way the other two are — it is read with a built-in default of 400 and you have to know the key exists. Second, the CSS one applies only when you have switched the **CSS Selector Extractor Implementation** dropdown to Jodd; leave it blank or on JSoup and the property is inert. None of these caches a parsed document. The exception is the CSS Selector Extractor, which — separately from the selector cache above — stashes the parsed body in the sampler context, so several CSS extractors under one sampler share a parse until post-processing of that sample ends. The JSON Extractor's map is also **per thread**, created lazily and discarded when the thread finishes, so the compilation is repeated once per thread rather than once per test. ## The single-expression elements are not a workaround The JSON JMESPath Extractor accepts exactly one expression — no semicolon lists, no `_ALL` checkbox — and reads the body into a document once per element. So pulling three fields out of one confirmation body costs three parses there too, just spread across three elements rather than looped inside one. The XPath2 Extractor is the same shape: one query, and it builds a fresh document per call. No JSON or XPath element in JMeter parses a body once and serves several expressions from the result. The one place JMeter does reuse a parse is the CSS Selector Extractor, which stashes the parsed body in the sampler context so several CSS extractors under the same sampler share it — but each of those still takes exactly one expression, so it is no help for a JSON body. If you genuinely need many fields from one large body and the parse is the thing you want to spend less of, the honest options are to reduce the number of expressions, or to parse once yourself in a scripting element — which is a different leaf's subject, and a real trade-off rather than a free win. ## What this changes about plan design - **One multi-value JSON Extractor versus several single-expression JSON readers is a readability decision, not a performance one.** Both cost one parse per expression. Choose on whether you want to disable captures individually and name elements meaningfully. - **Capture what you use.** An expression left in from debugging is a whole extra parse of every response, in every thread, for the life of the run. - **Scope narrows the work.** *Apply to: Main sample only* keeps the extractor off sub-samples; the default reads the main sample, and widening it to sub-samples multiplies the parses by the number of sub-samples. - **The extractor's Match No. does not affect parsing cost.** Extract-all and extract-first read the same document; the difference is only which variables get written. ## Where this stops being a JMeter question Knowing your plan asks for three parses per response is a fact about the plan. Deciding whether that parsing has turned your load generator into the constraint — and how you would prove it rather than assume it — is load-testing method, and it belongs with performance-workload fundamentals and bottleneck attribution, not with the element reference. JMeter's contribution is arithmetic: expressions per element, elements per sampler, samplers per iteration. What that arithmetic means for a run is somebody else's chapter.