httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Leggett" <>
Subject Re: mod_cache and its ilk
Date Mon, 30 Oct 2006 10:18:30 GMT
On Mon, October 30, 2006 12:07 pm, Joe Orton wrote:

> Thanks Roy.  So, the goals for mod_disk_cache as I see it:
> A simple general-purpose disk cache which makes no assumptions about
> speed of backend, speed of storage or speed of clients; is
> single-threaded and does not involve any multi-process synchronisation
> beyond open/O_EXCL.  Specifically:

So, as has been suggested before, I suggest we have mod_disk_cache that
implements the cache as described by Joe here, along with fixes to ensure
that it works (it currently doesn't).

Then, we have mod_large_disk_cache that does the extra stuff contributed
by Niklas Edmundsson. The end user can then make an intelligent choice as
to the best cache that fits their needs.

> 1) cannot write entire response to disk for any content type before
> sending anything to the client; filter acts by writing to cache and
> client synchronously

Justin vetoed this.

The mod_cache itself should be responsible for breaking any large buckets
into bite size chunks, to prevent the cache module from having to care
about large responses. This maintains the abstraction between
write-to-cache and write-to-network.

> A disk cache which makes different assumptions about speed of backend or
> uses more complex caching tricks should be in the tree as a different
> provider in a module with a different name; the exact assumptions made
> need to be well documented.  (Maybe something like
> "mod_local_disk_cache" would be appropriate for the name?)

+1 - I suggested mod_large_disk_cache, as it is taylored for large
responses, but I'm not attached to any specific name.

> Needless to say, code making bogus assumptions about the output
> filtering interface has no place in the tree and fails the "correctness"
> test.

Obviously, thus the notify solution.


View raw message