httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Leggett" <minf...@sharp.fm>
Subject Re: Possible new cache architecture
Date Tue, 02 May 2006 16:17:14 GMT
On Tue, May 2, 2006 5:50 pm, Brian Akins said:

> This seems more like a wish list.  I just want to separate out the cache
> and protocol stuff.

HTTP compliance isn't a wish, it's a requirement. A patch that breaks
compliance will end up being -1'ed.

The thundering herd issues are also a requirement, as provision was made
for it in the v2.0 design. The cache must deliver what the HTTP cache
requires (which in turn delivers what users require), not the other way
around.

Separating the cache and the protocol has advantages, but it also has the
disadvantage that fixing bugs like thundering herd may require interface
changes, forcing people to have to wait for major version number changes
before they see their problems fixed.

In this scenario, the separation of cache and protocol is (very) nice to
have, but not so nice that end users are disadvantaged.

>> - The ability to amend a subkey (the headers) on an entry that is
>> already
>> cached.
>
> mod_http_cache should handle.  to new mod_cache, it's just another
> key/value.

How does mod_http_cache do this without the need for locking (and thus
performance degradation)?

How does mod_cache guarantee that it won't expire the body without
atomically expiring the headers with it?

>> - The ability to invalidate a particular cached variant (ie headers +
>> data) in one atomic step, without affecting threads that hold that
>> cached
>> entry open at the time.
>
> mod_http_cache should handle.

Entry invalidation is definitely mod_cache's problem, it falls under cache
size maintenance and expiry.

Remember that mod_http_cache only runs when requests are present, entry
invalidation has to happen whether there are requests present or not, via
a separate thread, separate process, cron job, whatever.

>> - The ability to read from a cached object that is still being written
>> to.
>
> Nice to have.  out of scope for what I am proposing.  new mod_cache
> should be the place to implement this if underlying provider supports it.

It's not nice to have, no. It's a real problem that has inspired people to
log bugs, and very recently, for one person to submit a patch.

Regards,
Graham
--



Mime
View raw message