On Mon, 2008-08-18 at 19:20 -0700, John Caruso wrote: > I'd say it's still better, because it requires explicit action on the > user's part to enable the flawed caching mechanism in that case. And > actually I don't think fastpath in its default configuration would be of > much help in performance terms these days, given that the cache is only > 5MB large and file data is typically cached by the OS anyway (and servers > generally have far more RAM than they did even five years ago). >
fastpath is for small static content. You don't need to cache large files, and that is why the cachemaxsize parameter gives you a cutoff on the largest size to cache. AOLserver has great performance on small files, fastpath speeds it up further, plus the overall scheme handles directory files, internal redirects, etc. > I do think this should have been considered (and steps taken to address > it) when the fastpath caching mechanism was initially developed, since > it's a glaring flaw. I've designed things that rely on shaky underlying > assumptions in the past, but only in controlled circumstances where those > assumptions were guaranteed to obtain. I can think of situations in which > a caching mechanism with this type of design limitation wouldn't be an > issue, but in my opinion it has no place being a default-enabled mechanism > in an enterprise-grade web server. Why not just write another API which strips out all the things you don't like. I think you misjudge fastpath in every way, but whatever. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
