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.

Reply via email to