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
