httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Leggett" <minf...@sharp.fm>
Subject Re: cache: the store_body interface
Date Tue, 31 Oct 2006 09:43:17 GMT
On Mon, October 30, 2006 8:23 pm, Joe Orton wrote:

> 2) keep the interface as-is, but read buckets in mod_cache and partition
> the brigade manually; only pass a "small" brigade with known-length
> buckets to the provider. (so no morphing and no arbitrary memory
> consumption)

Thinking this through again after having a little more sleep.

The power of the current brigade interface lies in the fact that a cache
provider can, if it chooses to, modify the brigade in such a way as to
improve performance.

An extremely effective way of doing this is to replace expensive backend
buckets with cheap file buckets pointing at the cache file, or in the
memory cache case, cheap immortal buckets pointing at the memory cache
buffer. This makes it possible to read a response into the cache
completely and in the process release potentially expensive resources like
proxy connections or CGIs as soon as possible, rather than ages later,
when the client is finished the download.

Justin has argued that a default cache provider should be conservative in
its caching strategy, and this definitely makes sense.

But - the cache interface should not enforce a conservative strategy for
all caching modules.

Should an alternative cache provider want to cache more aggressively, it
should be empowered to do so by the interface.

The #3 option effectively "dumbs down" the interface, reducing the cache
to "store this and don't do anything else", and reduces the scope for
better caching methods.

My vote therefore goes with #2.

Regards,
Graham
--



Mime
View raw message