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.
*** Bug 29624 has been marked as a duplicate of this bug. ***
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.
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 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html). 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.
Added an initial implementation. URL: http://svn.apache.org/viewvc?rev=661482&view=rev Log: Bug 28502 - HTTP Resource Cache - initial implementation Needs work ...
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/1349