HTTP Request Samplers, Defaults, Headers, Cookies, and Cache Managers: Configuration, Design Patterns, and Trade-Offs
HTTP realism is selective. A maintainable test plan models only the protocol, session, cache, redirect, and resource behaviors that answer the performance question, while avoiding browser cargo-cult headers, hidden environment coupling, and result data that increases injector cost or privacy exposure.
Learning objectives
- Choose HTTP Request Defaults or sampler-local fields based on true shared configuration.
- Select Cookie/Cache Managers only when session/cache semantics belong to the workload.
- Choose redirect handling based on the measurement population you need.
- Decide whether embedded resources represent meaningful target traffic for the question.
- Choose keep-alive versus isolated connections without confusing connection churn with application latency.
- Design debug and load result capture as separate evidence profiles.
1. Design examples remain local and free
http://127.0.0.1:8000.
Paid load clouds, real identity systems, public websites, production
browsers, and managed observability are not required. The design
choices are demonstrated with the Chapter 05 local fixture.
2. Defaults versus duplicated sampler fields
| Pattern | Strength | Failure mode |
|---|---|---|
| Broad HTTP Request Defaults | One reviewable destination/client/timeout contract. | A broad host can accidentally affect a new sampler if scope is unclear. |
| Repeated host/port in each sampler | Sampler appears self-contained. | Environment changes require many edits and drift is easy. |
| Defaults + narrow override | Good for a deliberate exception. | Too many overrides recreate hidden duplication. |
Use Defaults for environment-level invariants: implementation, protocol, host, port, and conservative timeouts. Keep business operation fields such as method/path/body on samplers.
3. Cookie/cache simulation versus stateless API traffic
Stateful web journeys often need server-issued cookies and browser-like HTTP caching. Stateless APIs may use an independent authorization mechanism and explicit cache behavior. Adding Cookie/Cache Managers to a stateless workload can introduce state that the real client does not have.
Conversely, omitting Cookie Manager from a session-based application can make every sampler look unauthenticated. Model actual protocol state, not a generic “web test” template.
5. Automatic redirects versus explicit/followed steps
| Choice | Use when | Measurement consequence |
|---|---|---|
| Follow Redirects | You need the user-visible final result while retaining redirect-chain evidence. | Parent elapsed/bytes include chain; child results can expose hops. |
| Redirect Automatically | You only need the final protocol-handler behavior for GET/HEAD and do not need JMeter-visible redirect hops. | Intermediate redirects hidden from sample visibility. |
| No follow + explicit next sampler | The redirect and destination are separate business/protocol steps you want labeled independently. | You own ordering and transaction grouping explicitly. |
For authentication/payment redirect chains, explicit visibility may be critical. For a static canonicalization redirect, the chain might be incidental. The answer depends on the question—not on a universal JMeter setting.
6. Embedded resources versus API-focused requests
Retrieving HTML embedded resources can better approximate HTTP traffic generated by a page load: CSS, scripts, images, frames, and related assets. It can also multiply requests, alter connection concurrency, hit CDNs/third parties, and change result populations.
In an API-focused test, disable it. In an authorized web-protocol test, use URL include/exclude filters to prevent accidental third-party requests and document concurrent-pool settings. Even then, JMeter does not execute JavaScript or render the page.
7. Connection reuse versus isolated connections
Persistent connections reduce repeated TCP/TLS establishment overhead and resemble common modern HTTP client behavior. Isolated connections may be useful when the client truly reconnects or when you specifically test connection establishment.
Do not disable keep-alive merely to “stress the server more.” That changes the workload to a connection-churn test and can move the bottleneck to ephemeral ports, TLS handshakes, network devices, or injector sockets.
8. HttpClient4 versus Java implementation
Current HTTP Request supports Java and HttpClient4. The Java implementation has documented limitations, including less control over connection reuse and several advanced HTTP features. This course pins HttpClient4 for deterministic teaching of keep-alive, method support, and manager behavior.
This is a test-plan dependency. Record it in the JMX/run manifest instead of saying only “JMeter 5.6.3.”
9. Response retention versus lean JTL
Detailed response bodies and headers are excellent for a one-thread debug run and expensive/risky under load. Current JMeter CSV defaults already avoid response bodies, sampler data, request headers, and response headers. Keep that lean pattern unless a specific diagnostic requires more.
If a failed sample needs response content, decide whether
response_data.on_error is safe for the data sensitivity
and expected failure volume. Do not enable it globally for real
credentials/customer data without a privacy review.
For every load-oriented design comparison, preserve the lean JTL
together with the matching jmeter.log. The JTL
describes sample outcomes; the engine log preserves JMeter-side
startup/runtime diagnostics and prevents protocol conclusions from
being based on sample data alone.
10. Worked scenario: browser-backed web app versus JSON service
| Concern | Web journey | Stateless JSON service |
|---|---|---|
| HTTP Defaults | Shared target + HttpClient4 + timeouts. | Same. |
| Cookie Manager | Yes if server session uses cookies. | No unless API actually uses cookies. |
| Cache Manager | Maybe, when browser-cache semantics affect traffic. | Often no; follow API/client cache contract. |
| Embedded resources | Maybe for page-level HTTP traffic. | No. |
| Redirects | Often Follow Redirects or explicit steps. | Usually explicit only if API legitimately redirects. |
| Headers | Small intentional browser/protocol set. | Accept/Content-Type and real API requirements. |
| JTL | Lean under load. | Lean under load. |
11. Keep HTTP-plan state separate from surrounding systems
| Layer | Examples | Do not confuse with |
|---|---|---|
| JMeter HTTP plan | sampler/defaults/header/cookie/cache/redirect options | JVM heap. |
| JVM/generator | heap, CPU, sockets, DNS | server cookie/session semantics. |
| OS/network | TCP/TLS/DNS/firewall | HTTP assertion correctness. |
| SUT | session store, caches, redirect logic, CDN/backend | JMeter cache state. |
| CI/container | workspace, network namespace, CPU quota | whether localhost means host service. |
12. Decision table
| Decision | Prefer A | Prefer B | Evidence required |
|---|---|---|---|
| Defaults vs duplicate fields | Shared destination/client settings. | Truly sampler-specific destination. | Resolved sampler config + JMX diff. |
| Stateful vs stateless | Application uses cookie/cache session behavior. | Client protocol has no such state. | Server logs + session/cache behavior. |
| Follow vs automatic redirect | Hop visibility matters. | Only final GET/HEAD outcome matters. | Redirect labels/subresults + target log. |
| Embedded resources on/off | Page resource HTTP traffic matters. | API/business endpoint only. | Target path counts + filters. |
| Keep-alive on/off | Persistent client behavior is realistic. | Connection establishment is itself the test. | Client-port/connect-time + generator/network state. |
| Rich vs lean results | Tiny bounded debug. | Meaningful load/CI. | JTL schema + privacy/resource rationale. |
Knowledge check
Why is a manually entered session cookie a poor way to simulate many users?
Manual Cookie Manager entries are shared by threads, so users can collapse onto one session and the value may also expose sensitive state.
When should Retrieve All Embedded Resources remain off?
When the workload is API-focused or page assets are outside the performance question/authorization envelope.
Why can disabling keep-alive change the bottleneck?
It adds connection-establishment churn, which consumes injector/target/network socket and handshake resources unrelated to the original application workload.
What is the privacy advantage of lean CSV JTL defaults?
Response bodies, sampler data, and request/response headers are not retained by default, reducing artifact size and accidental sensitive-data capture.
Why does the course pin HttpClient4 in Defaults?
It makes connection/client semantics explicit and avoids relying on installation-level implementation selection.
Official references and version notes
- Component Reference — current HTTP Request, HTTP Request Defaults, HTTP Header Manager, HTTP Cookie Manager, HTTP Cache Manager, redirect, keep-alive, and embedded-resource semantics.
- Elements of a Test Plan — scope and execution architecture around samplers and configuration elements.
- Properties Reference — current CSV/JTL save fields and defaults such as response/request header retention and connect time.
- Functions and Variables — thread-local runtime values and function boundaries.
- Getting Started — GUI authoring/debugging versus CLI load execution.
- Best Practices — lean load generation and result/listener guidance.
- Apache JMeter downloads — current production release and release-specific Java requirement.
Version-sensitive statements were rechecked against current Apache JMeter primary documentation on 2026-09-04. The course baseline remains Apache JMeter 5.6.3 with a Java 17 JDK for labs and no third-party plugins; JMeter 5.6.3 itself requires Java 8+. HTTP labs explicitly select HttpClient4 in HTTP Request Defaults rather than relying on inherited/default implementation selection. Current docs state that response cookies handled by one HTTP Cookie Manager are stored per JMeter thread, while manually configured cookies are shared by threads. HTTP Cache Manager keeps a separate cache per virtual-user thread. Redirect Automatically hides intermediate redirects from JMeter and should only be used for GET/HEAD; Follow Redirects lets JMeter follow the chain and retain redirect child samples while the parent elapsed/bytes include the chain. Use KeepAlive is controllable with the Apache HttpComponents implementation. Embedded-resource retrieval parses HTML/CSS references and sends additional HTTP requests; it does not execute a browser DOM, render pixels, run application JavaScript, or reproduce Selenium/browser behavior.
Keep the academy open
Support free, practical DevOps education.
Every lesson is designed to remain readable in a browser, downloadable from GitHub, and usable without a paid learning platform. Contributions help expand and maintain the curriculum.
0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0
Send only Ethereum/ERC-20 compatible assets to this
address.