httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: cache: the store_body interface
Date Tue, 31 Oct 2006 10:43:55 GMT
On Oct 31, 2006, at 1:59 AM, Nick Kew wrote:
> It was not intended as any such thing.  Just a comment noting
> that we have an extremely simple case in which this caching
> strategy will degrade system performance not just a little,
> but by a whole order of magnitude.  The lusers will love it.

Okay, but -1 means veto -- -0.9 means "I think it sucks."

> I'm not vetoing anything in mod_cache.  I'm nowhere near
> familiar enough with it for that.  But I do know that
> "I wouldn't start from here": by bypassing the normal request
> processing cycle, it's introduced a lot of extra complexity
> for a very questionable gain (would you use mod_cache to
> serve local, static contents?)

No, but the method is equally applicable to large pipes,
app servers, etc.  And the trade-off of simplifying the store
body process (as opposed to trying to tee a brigade) makes sense
to me.  If the cache is configured, the brigade is stored in
the cache in one pass while writing the response downstream.
If the cache is not configured for a given URL, then local
file handling using efficient brigades is left unchanged.

You say that the strategy will degrade performance, but you
don't indicate why.  If there is some great performance penalty
caused by changing the interface to send_body, I'd like to know
what it is.

....Roy

Mime
View raw message