httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@apache.org>
Subject Re: alternate caching proposal
Date Fri, 18 Jan 2002 16:40:16 GMT
Graham Leggett wrote:
> This is a cryptographically signed message in MIME format.
> 
> --------------msCEBA12FF9ED7450117A571A8
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> 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?
>>

unfortunatly I couldn't get the input filter working at all. and due to 
this I don't even thing you can do what I proposed. thats why the 
quick_handler hook was modified so that it is in the internal_request now.

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

yep.. agreed, but if you can't configure it then it is next to useless
for large sites where parts of their page are always dynamic.
the current design might serve a page, but it ignores things like notes,
which makes logging hard.

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

it is. it is.
nothing I intend on doing will >require< an extra config directive.


for caching subrequests, all that is required IMHO is to change the 
SUBREQ_CORE outputfilter so that it runs as a '20' not a '10'.
there is a bug somewhere in the CACHE_OUT filter which is causing it to 
not act nicely.. but thats a bug, not a config option.

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

how about this.
if the filter-stack is in place, it will use it, if not it will add it.
from what I can see in the code, it already does this.

> 
> Regards,
> Graham
> 




Mime
View raw message