Configuration Elements — Defaults, Cookies, Cache

Configuration elements set up the context that samplers run inside. They do not send requests themselves — they define defaults, manage session state, and handle infrastructure concerns so that every sampler in scope inherits the right environment without repeating the same settings across dozens of requests.

HTTP Request Defaults

If your test plan targets the same server across every sampler, HTTP Request Defaults lets you define the host, port, and protocol once instead of on each request.

Add it via right-click → Add → Config Element → HTTP Request Defaults. Place it at Thread Group level to apply to all HTTP samplers in that Thread Group.

Configure:

• Server Name or IP: api.example.com
• Port Number: 443
• Protocol: https
• Path: leave blank (each sampler defines its own path)
• Content Encoding: UTF-8

Any field left blank in an HTTP Request sampler inherits the value from HTTP Request Defaults. Any field you fill in on the sampler overrides the default. This means you can set the base URL once and have 50 samplers each define only their path.

When the target server changes — for example, switching from staging to production — you change one field in HTTP Request Defaults instead of 50 sampler configurations. This is the single highest-leverage configuration change you can make in any multi-sampler test plan.

HTTP Header Manager

HTTP Header Manager adds HTTP headers to every request in its scope.

Common headers to apply globally:

Authorization: Bearer ${authToken}
Content-Type: application/json
Accept: application/json
X-Request-ID: ${__UUID}

Place the Header Manager at Thread Group level for headers that apply to all requests. Add a second Header Manager as a child of a specific sampler for headers that apply to only that request. Both are merged — the sampler-level header wins on conflicts.

One important detail: when you add Content-Type in a Header Manager, remove it from the HTTP Request sampler's own Body Data configuration if it appears there. Duplicate Content-Type headers can cause servers to reject requests with a 400.

HTTP Cookie Manager

Web applications that maintain sessions via cookies require an HTTP Cookie Manager. Without it, JMeter sends every request without cookies — the server sees each request as unauthenticated, and session-based flows break.

Add it at Thread Group level. Once added:

• After a successful login request returns a Set-Cookie header, JMeter stores the cookie automatically.
• Every subsequent request in the same thread sends that cookie in the Cookie header.
• The cookie jar is per-thread — each VU maintains its own independent session.

Clear cookies each iteration: check this if you want each loop to start as a fresh, unauthenticated user. Leave it unchecked if a logged-in user should persist across iterations.

Cookie Policy: use standard for most modern web applications. Use compatibility for legacy systems that do not fully follow the cookie RFC.

HTTP Cache Manager

HTTP Cache Manager simulates browser caching behaviour. Without it, JMeter fetches every static resource on every request — even CSS, JavaScript, and image files that a real browser would cache after the first page load.

For browser-based user simulations, add the Cache Manager at Thread Group level. It respects Cache-Control, Expires, and ETag headers from the server and skips cached resources on subsequent requests, just as a browser would.

For API load testing where every request is a unique call, the Cache Manager is unnecessary and can be omitted.

HTTP Authorization Manager

For applications protected by HTTP Basic, Digest, NTLM, or Kerberos authentication, the Authorization Manager handles the auth handshake automatically.

Add one entry per protected URL prefix:

Base URL: https://api.example.com/admin
Username: ${adminUser}
Password: ${adminPass}
Domain: (blank for Basic/Digest)
Mechanism: BASIC

JMeter sends the Authorization header automatically on any request whose URL starts with the configured base URL — no need to add the header manually to each sampler.

Counter and Random Variable

Counter generates a sequential integer that increments per-thread or globally across all threads.

Configuration:

• Starting value: 1
• Increment: 1
• Maximum value: 9999 (resets to starting value when reached)
• Variable name: orderId
• Track counter independently for each user: check this for per-thread counters

Reference it as ${orderId} in any sampler body, URL, or header. Each call to the Counter element advances the value by the increment.

Random Variable generates a random integer within a range at the start of each iteration.

Configuration:

• Minimum value: 1
• Maximum value: 10000
• Variable name: productId
• Per-thread: True

Use it when you want random access patterns — for example, fetching a random product ID on each iteration — without the per-call overhead of the __Random function.

⚠️ Common mistakes

• Missing Cookie Manager for session-based applications. If your application requires login and the test shows all requests after login returning 401 or redirecting to the login page, the Cookie Manager is missing. The login response set a session cookie but nothing captured or forwarded it. Add one HTTP Cookie Manager at Thread Group level.
• Duplicate Content-Type headers. Setting Content-Type in both the HTTP Header Manager and a sampler's explicit header configuration results in two Content-Type headers in the request. Most servers reject this with a 400. Define Content-Type in exactly one place.
• HTTP Request Defaults at Test Plan level overriding intentional per-group differences. If Thread Group A targets a staging server and Thread Group B targets a mock, placing HTTP Request Defaults at Test Plan level forces both groups to the same server. Place defaults at Thread Group level when groups have different targets.

🎯 Practice task

Add configuration elements to your existing test plan.

1. Open first-test.jmx. Add an HTTP Request Defaults at Thread Group level with server test.k6.io and protocol https. Remove the server name from both existing HTTP Request samplers — confirm they still run correctly, inheriting the default.
2. Add an HTTP Header Manager at Thread Group level with Accept: application/json. Run and check the Request tab in View Results Tree — confirm the Accept header appears in every request.
3. Add an HTTP Cookie Manager at Thread Group level. Add a request that logs in first (or simulates one), then add a request to a protected endpoint. Observe whether cookies are forwarded automatically.
4. Add a Counter config element with variable name requestId, starting at 1, increment 1. Add ${requestId} as a query parameter to one of your HTTP Requests. Run with 5 users, 3 loops. Confirm the counter increments correctly — check whether it counts per-thread or globally depending on your configuration.