- Author: [[Tim Koopmans]] on [[flood.io]] - Full Title: Understanding the JMeter Cache - Flood - Tags:: [[Cache management]] [[Cache]] [[Cache Headers]] [[Cache]] [[Cache management in JMeter]] - URL: https://www.flood.io/blog/understanding-the-jmeter-cache - ### Highlights first synced by [[Readwise]] [[2021-01-20]] - The main reasons for caching are to reduce latency and network traffic between a client and origin server - browser's local cache. This lets you keep representations of content on local storage - Other caches, such as proxies, can exist between your browser cache and the origin server - intermediary caching obviously impacts the workload profile of the origin server itself. Often these are outside of your control, and are particularly prevalent in any form of testing outside of a controlled network environment. - Fresh content is typically served straight from the browser cache, whilst validated content will avoid requesting the same content if it hasn't changed. Cache management, in terms of determining if content is stale or fresh, is mostly implemented via HTTP headers. - Pragma: no-cache Pragma headers specify optional behaviour. The Pragma: no-cache header is only defined for backwards compatibility with HTTP/1.0 and is equivalent to the Cache-Control: no-cache header directive. Some caches will simply ignore the Pragma directive so it's not a great way of ensuring content is not cached. - Cache-Control Cache-Control headers were introduced in HTTP/1.1 to specify directives that must be followed by all caching implementations in the request/response chain. The common Cache-Control directives you will come across are: public private no-cache no-store no-transform must-revalidate proxy-revalidate max-age s-maxage - The Expires header gives the date/time after which the response is considered stale. The presence of an Expires header field with a date value of some time in the future on a response that otherwise would by default be non-cacheable indicates that the response is cacheable, unless indicated otherwise by a Cache-Control header field. Last Modified The Last-Modified header field indicates the date and time at which the origin server believes the variant was last modified. ETag The ETag header field provides the current value of the entity tag for the requested variant. - The JMeter HTTP Cache Manager is used to add caching functionality to HTTP requests within its scope. Essentially it will check response headers and respect the majority of headers related to cache management around Expires, ETag and Cache-Control directives. - It implements a per-user/thread Map which has a maximum size and uses a Least Recently Used algorithm to remove items from the Map when the maximum size is reached and new items are added. The default size is 5000 items, an item being stored as the URL along with Last Modified, Expires and ETag header information. It's possible to increase this value, however setting an appropriate value for this is difficult with no feedback from JMeter itself. - When using the JMeter Cache Manager you can expect to see HTTP response codes 304 or 204. When JMeter makes a conditional GET request but the document has not been modified, a server will typically respond with a 304 response code and no response body. - Thread Name: Thread Group 1-1 Sample Start: 2013-10-29 20:20:07 EST Load time: 3 Latency: 0 Size in bytes: 150 Headers size in bytes: 150 Body size in bytes: 0 Sample Count: 1 Error Count: 0 Response code: 304 Response message: Not Modified When JMeter simulates using content directly from its cache, it will record a 204 response code and no response body. Thread Name: Thread Group 1-1 Sample Start: 2013-10-29 20:20:07 EST Load time: 0 Latency: 0 Size in bytes: 0 Headers size in bytes: 0 Body size in bytes: 0 Sample Count: 1 Error Count: 0 Response code: 204 Response message: No Content - no actual requests are made to the origin server in this case. - ### New highlights added [[2021-01-21]] at 6:08 PM - > If a no-cache directive is set, JMeter will keep this in cache, but set the expires date to null which will trigger a revalidation for each request. You will generally see a HTTP response code 304 for this type of conditional request. ([View Highlight](https://instapaper.com/read/1378461920/15251796)) - > no-store If sent in a response, a cache MUST NOT store any part of either this response or the request that elicited it. ([View Highlight](https://instapaper.com/read/1378461920/15251799)) - > if the "Use Cache-Control/Expires header" option is selected in the Cache Manager, JMeter will issue a HTTP response code 204 for content in its cache, otherwise it will make a conditional request and you will see a HTTP response code 304 where appropriate. ([View Highlight](https://instapaper.com/read/1378461920/15251803)) - The JMeter HTTP Cache Manager is used to add caching functionality to HTTP requests within its scope. Essentially it stores a copy of the URL along with Last Modified, Expires and ETag headers taken from the response in a Hash Map which will evict items based on a Least Recently Used algorithm. It will typically record HTTP response codes 204 or 304 for items which are cacheable and meet freshness or validation criteria. Response body will be empty for these items so you need to be careful with any assertions on content. ([View Highlight](https://instapaper.com/read/1378461920/15251813))