Bug 28502

Summary:	HTTP Resource Cache
Product:	JMeter - Now in Github	Reporter:	Thad Smith <thads_id>
Component:	HTTP	Assignee:	JMeter issues mailing list <issues>
Status:	RESOLVED FIXED
Severity:	enhancement	CC:	remedyqa
Priority:	P2
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	All

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 
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.

Comment 4 Sebb 2008-05-29 14:29:03 UTC

Added an initial implementation.

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

Needs work ...

Comment 5 The ASF infrastructure team 2022-09-24 20:37:32 UTC

This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/1349