Bug 28502 - HTTP Resource Cache
Summary: HTTP Resource Cache
Alias: None
Product: JMeter
Classification: Unclassified
Component: HTTP (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement with 2 votes (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
: 29624 (view as bug list)
Depends on:
Reported: 2004-04-20 14:50 UTC by Thad Smith
Modified: 2010-08-17 12:12 UTC (History)
1 user (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Thad Smith 2004-04-20 14:50:51 UTC
We have the ability for our http requests to retrieve embedded resources such 
as images, javascript files, css's and applets. The problem is that JMeter will 
download each resource in a page from the server and doesn't have the ability 
to check if a previous request downloaded the same resource. 

What I'm proposing is a new config element called HTTP Resource Cache that will 
store embedded resources the same that a browsers cache will. Each time a 
request retrieves an embeddded resource it will check the cache to see if it 
already has a copy of the resource. If it does it will simply copy or point to 
the resource in the cache. If it doesn't it will download the resource and 
store it in the cache.

This will the user to more accurately simulate a real browser's impact on the 
network and load against an http server.
Comment 1 Sebb 2005-02-18 04:18:27 UTC
*** Bug 29624 has been marked as a duplicate of this bug. ***
Comment 2 Alf Hogemark 2007-04-22 09:38:10 UTC
This is actually something I thought about a couple of months ago, without
seeing this bug. Then I saw this bug, and since other people also seems to want
this functionality, I might look into making such functionality.

For my part, this functionality would be useful in two aspects. Mainly, it would
mean that the sampling when ticking on "download images" would be more accurate.
But it would also be useful to check that the "caching headers" sent by the web
servers are correct, i.e. to check that clients actually uses the cached version.

My main concern is how complex and fancy this functionality should be made.
First there is the logic to store the caching headers and information received
for each request, so it can be used in subsequent caches. I've written some code
for that.
Then the http samplers need to use the caching information, to send HTTP HEAD
requests and so on, to check with the server if the cache is still valid and so
on. I haven't looked into this now.
Finally, if the test plan contains "assertions" that work on the response, it
means that the sample must get the sample response data that was cached.

For the GUI part, I' thinking about options like "Max memory size for cache" and
"Max disk size for cache", to emulate both memory and disk browser cache.

I write this comment now, because I noticed on the mailing list, that the
priority was changed from P3 to P2, so I see there is some interest at the moment.
It would be nice if other people could tell what functionality they need at a
minimum, and what functionality could be fancy / nice to have.

I think this bug is one of the few remaining "big items" for new functionality
that is missing in JMeter, with regards to web page testing.
Comment 3 Sebb 2007-12-05 17:05:55 UTC
Browsers may still make requests for cached items, however the requests are 
conditional, i.e. they use If-Modified-Since and If-None-Match qualifiers (see 

The sample result for cached items would in general have a different size and 
download time; this would be correct for calculating network and server 
throughput, but maybe not for other purposes.
Comment 4 Sebb 2008-05-29 14:29:03 UTC
Added an initial implementation.

URL: http://svn.apache.org/viewvc?rev=661482&view=rev
Bug 28502 - HTTP Resource Cache - initial implementation

Needs work ...