Re: mod_cache responsibilities vs mod_xxx_cache provider responsibilities

[Davi Arnaut <da...@haxent.com.br>]

On 14/09/2006, at 08:48, Graham Leggett wrote:

> On Thu, September 14, 2006 1:42 pm, Davi Arnaut wrote:
>
>> This is not a top priority since actually there is no complete
>> support for it in mod_cache (partial responses and such), but it
>> would be nice to have it.
>
> HTTP/1.1 compliance is mandatory for the cache. If it doesn't work  
> now, it
> needs to be fixed.

The cache is required to send to the client the most up-to-date  
response, it doesn't mean it must cache it.

What I meant is _if_ it causes significant slowdowns for a common  
cache hit path _probably_ it is better to just revalidate the hole  
entity.

--
Davi Arnaut

Re: mod_cache responsibilities vs mod_xxx_cache provider responsibilities

[Graham Leggett <mi...@sharp.fm>]

On Thu, September 14, 2006 2:07 pm, Davi Arnaut wrote:

> The cache is required to send to the client the most up-to-date
> response, it doesn't mean it must cache it.

As I recall once cached, if an entry is stale and is revalidated, the
headers coming back with the 304 Not Modified must replace the headers in
the cache.

> What I meant is _if_ it causes significant slowdowns for a common
> cache hit path _probably_ it is better to just revalidate the hole
> entity.

The point behind the cache is that the cache is cheap, while the backend
is expensive. A cache slowdown usually isn't critical, as the cache is
usually significantly faster than the backend. Trying to save a few cycles
in the cache by hitting the backend unnecessarily gives you little
performance gain.

Regards,
Graham
--