httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: cache trouble (Re: [vote] 2.1.9 as beta)
Date Thu, 03 Nov 2005 19:44:02 GMT


On 11/03/2005 11:01 AM, Nick Kew wrote:
> On Wednesday 02 November 2005 20:26, William A. Rowe, Jr. wrote:
> 
>>Colm MacCarthaigh wrote:
>>

[..cut..]

>>
>>Certainly not in <Directory /foo> - the cached entity no longer lives
>>there.
> 
> 
> I disagree.  If it came from there originally, then that's where it lives.
> The principle we want here is that retrieving from cache should have
> the same rules from a client PoV as retrieving an original unless a
> sysop explicitly says otherwise.  Breaking that principle shouldn't
> hit the sysop as a standard or default behaviour.
> 

I agree with Nick on this as this creates the potential for confusion
on user side. It also make the behaviour inconsistent for already cached data
and data that gets cached the first time. From developer perspective I understand
the performance penalties of doing so.


> 
> I'm not convinced by that either.  In fact, I dislike the whole "run it in a
> quick handler" principle - it runs a supertanker through the KISS principle,
> and has consequently left us with a cache that never really worked.
> Even if we fix this, it's sure to have a high bugrate for the forseeable
> future precisely because it violates KISS.
> 
> The main purpose of caching is to relieve the pressure on a big, slow backend.
> In real life, most of that bigness and slowness is pretty much always going to 
> live in a handler or a backend, so what we save by running quick_handler is
> inherently of secondary importance.  And there are several things we can

In the cases you describe here (and for what I use it personally) I agree, but for other
cases, e.g. the one Colm uses it (storing cached data on faster disks, than
the uncached data) I think running in handler is a pain.
I think in principle, it would be fine to choose via a configuration directive where to
run mod_cache as Paul's patch suggested. What is currently bothering me about this idea
is that this is a nice thing for people with inside view, but it is not really
transparent to users. So what this configuration option actually does from the users
perspective must be expressed more clearly by doing this configuration.
Maybe a good name for this directive can be enough.


[..cut..]

> 
>>And maybe, have you considered a <CachedLocation > / <CachedLocationMatch
>
>>container for mod_cache?  This would have the benefit that very long lists
>>of directives would be ignored/not merged, in favor of a much shorter and
>>very specific list that benefits the cache by keeping it fast, while giving
>>the user the option to tweak the behavior of content, once cached.
> 
> 
> You mean as a tool for sysops to accept/decline serving from cache?
> That could potentially have merit, and would work best in a quick-translation
> hook to bypass any more complex/expensive rules.
> The danger is if it grows some nightmarishly confusing relationship
> to normal <Location> semantics: the existing <Location> vs <Directory>
> is bad enough for non-expert users!
> 

I also agree with this. While I understand the performance benefits from the
developer perspective, I fear the confusion from the user and administrators perspective.
Having a clear configuration is not only about having non-expert
users getting it work but also to ease the job of expert administrators to understand
what they configured a year or so after they did :-).

Regards

RĂ¼diger


Mime
View raw message