Using the HTTP Cache Manager
Web-browsers have some mechanisms which allow for the reduction of traffic over the Internet. One such item is the caching of resources downloaded from the network, for use in the subsequent requests without triggering the web-server. That’s why it’s extremely important to reproduce the same behaviour while creating a performance test.
How does the HTTP Cache Request work in JMeter?
The first time you test, when a certain URL is requested from the server, JMeter saves the results to RAM.
Every resource file has the following: HTTP Header — Last-Modified.
The Last-Modified entity-header field indicates the date and time at which the origin server believes the variant was last modified.
Last-Modified = “Last-Modified” “:” HTTP-date
An example of its use is:
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
Another header, which is used for identifying copy of file is the ETag.
The ETag response-header field provides the current value of the entity tag for the requested variant.
This header is used as a pair with If-None-Match header.
For example, if the resource comes with the Etag=”737060cd8c284d8af7ad3082f209582d”, then the next request will be sent with IF-NONE-MATCH=”737060cd8c284d8af7ad3082f209582d”, which will be equal to the received ETag.
Both these headers are used by the browser for caching functionality.
Again. When JMeter receives some resources (e.g. sample has response code 2xx), then the Last-Modified and ETag (and Expired if relevant) values are saved for the URL.
Before executing the next sample, the sampler checks to see if there is an entry in the cache, and if so, the If-Last-Modified and If-None-Match conditional headers are set for the request.
OK. Let’s see, which controls the HTTP Cache Manager does have.
Number Attribute Description Required
• Clear cache each iteration If selected, then the cache is cleared at the start of the thread. YES
• Use Cache Control/Expires header when processing GET requests See description above. YUP
• Max Number of elements in cache See description above. YUH-HUH
The most significant, from our perspective is the Max Number of elements in cache(3). By default, it is equal to 5000 but it can be increased.
Note. All resources are cached in RAM so, in the scenario where this parameter is too high, you will easily get an OutOfMemoryException. To avoid such behavior, you should adjust JVM-Xmx option in jmeter.bat\sh.
Use Cache-Control/Expires header(2) — if this option is selected, then the Cache-Control/Expires value is checked against the current time. If the request is a GET request, and the timestamp is in the future, then the sampler
returns immediately, without requesting the URL from the remote server. This is intended to emulate browser behaviour.
This parameter deserves deeper explanation.
• If the requested document has not changed since it was cached, then the response body will be empty.
• If the requested document has not changed, than it will be taken from cache. And, obviously, this will influence response time — it will become much shorter.
All this may lead to failed requests, if they are used along with Assertions. Since theory is often scoffed at, we’ll show you an actual example.
We’ve taken a very simple test-scenario, which consists of one HTTP Request Sampler. Don’t pay attention to the two child assertions of this request right now, we’ll come back to them a little bit later.
Don’t set Use Cache-Control/Expires, now run the test-scenario.
Open the View Results in the Table and see the results.
We see that all response-times are 1–2 sec. Now we’ll set Use Cache-Control/Expires and run the test-scenario again.
Note, that all values: Sample Time, Bytes, Latency-are less now than in the previous test run.
Now turn back to the two child assertions in the HTTP Request, Duration and Size. The received test results prove that using the Cache-Control/Expires will influence the percentage on failed/passed requests in the cases where the test-scenario is created with assertions. And, keep that in mind.
