How to add a Cache Manager in JMeter

Browser-oriented load tests behave differently when every repeated asset request reaches the origin. A JMeter HTTP Cache Manager gives each virtual user its own HTTP cache, so repeat page views can reuse fresh cached responses or send conditional requests instead of downloading the same cacheable resource on every loop.

The cache manager belongs in the same scope as the HTTP samplers it should affect, most often under the relevant Thread Group. It stores cache entries per virtual user thread, and the default cache size is intended for ordinary browser-like reuse rather than a shared cache across all users.

Cache behavior depends on the response headers returned by the target application. A fresh GET response with Cache-Control or Expires can be skipped by JMeter on the next identical request, while expired or no-cache responses can still produce conditional requests with validators such as ETag or Last-Modified.

1. Open the test plan in the JMeter GUI and select the Thread Group that owns the repeated HTTP requests.
2. Add the cache manager under that Thread Group from Thread Group → Add → Config Element → HTTP Cache Manager.
3. Name the element for the cached traffic it covers.
4. Leave Clear cache each iteration disabled when loop iterations should behave like repeat page views from the same browser session.

   Enable this option only when every loop must start with an empty browser cache. Enabling it prevents the next loop from reusing entries saved by the previous loop.

5. Select Use Cache Control/Expires header when processing GET requests.
6. Keep Max Number of elements in cache at 5000 unless the plan downloads more unique cacheable resources per virtual user.

   Larger cache limits increase memory use because each virtual user thread has its own cache.

7. Save the test plan.
8. Confirm that the target response returns cache headers before relying on the cache manager.

   $ curl -sSI http://app.example.net/assets/app.js
   HTTP/1.1 200 OK
   Content-Type: application/javascript
   Cache-Control: max-age=120
   ETag: "asset-v1"
   Last-Modified: Mon, 29 Jun 2026 00:00:00 GMT
   Content-Length: 25

   A response without a freshness header or validator gives the cache manager little to reuse or revalidate.
   Tool: Hypertext Transfer Protocol (HTTP) Header Checker

9. Set the Thread Group loop count to 2 for a short cache smoke test.

   Use an existing repeated page-view path if the plan already requests the same cacheable resource more than once.

10. Run the saved plan in non-GUI mode.

    $ jmeter -n -t cache-manager-demo.jmx -l cache-manager-results.jtl
    Creating summariser <summary>
    Created the tree successfully using cache-manager-demo.jmx
    Starting standalone test @ 2026 Jun 29 21:44:52 GMT (1782769492666)
    Waiting for possible Shutdown/StopTestNow/HeapDump/ThreadDump message on port 4445
    summary =      1 in 00:00:00 =   12.0/s Avg:    14 Min:    14 Max:    14 Err:     0 (0.00%)
    Tidying up ...    @ 2026 Jun 29 21:44:52 GMT (1782769492792)
    ... end of run

    Related: How to run a JMeter test from the command line

11. Check the target server or mock endpoint access log for one origin hit during the two-iteration smoke test.

    $ cat cacheable-server.log
    server=listening port=18081
    request method=GET path=/assets/app.js if_none_match=-

    One origin request for two identical iterations confirms that the second request was satisfied from the virtual user's cache while the cached response was still fresh.

12. Restore the normal Thread Group loop count if it was changed only for the smoke test.