httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: alternate caching proposal
Date Fri, 18 Jan 2002 15:48:11 GMT
Ian Holsman wrote:

> I was wondering if it would be better if we replaced
> how it slots in so that instead of IT pushing filters
> onto the output chain and relying on the 'quick' hook
> it could be done like
> 
> http://holsman.net/test/cache.png
> 
> where the CACHE filters are specified via setoutputfilter/setinputfilter
> 
> I think this would be better because
>         a) we could cache intermediate results if needed
>         b) we could cache subrequests
> 
> So what do you guys think of it
> this design asssumes that we could short-circuit all the hooks
> is this possible?

The basic concept of the original design is that in its default config,
the cache would try to maximise performance as a primary goal. To
achieve this CACHE_OUT would have to be as close to the very first
filter as possible, and CACHE_IN would be as close to the very last
filter as possible, so as to "cover" as much of the apache filter chain
as it can.

Adding additional configurability so that things like subrequests, etc
can be cached is a good thing, however the original design goal - ie
maximise performance in it's default config should be kept.

I'm worried that with all the additional functionality, actually
configuring the cache will be a source of confusion. Currently people
can set caching on or off based on URL prefix - if they have to fiddle
with the filter stack manually in addition to this it will become too
complicated to use.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."
Mime
View raw message