HTTP server choices?

David Shaffer cdshaffer at acm.org
Wed Jan 4 14:39:39 UTC 2006


goran at krampe.se wrote:

>
>I actually didn't do file serving. :)
>  
>
Yes, this is common.  There are a lot of people using ModFile though so
it seemed worth talking about.  Personally I try to serve static content
through apache.


>
>
>Well, I thought they looked pretty ok - not sure what sub-standard
>means. And I did use Linux as the platform.
>
>  
>
Yes, I'm sorry "standard" is certainly ambiguous...for servlet (non
file-based) applications I base my standards of web server performance
on a rough average of:

       Jigsaw serving a Java servlet
       Tomcat serving a Java servlet
       Python's BaseHttpServer serving a python servlet

These choices may seem arbitrary but they represent the world that I
live in.  If you compare Squeak to say Ruby/Webbrick then we aren't so
sub-standard.  Anyway for my standards: in each case the servlet should
be relatively simple so that the time to generate the response is as
small as possible while still producing the desired response size (the
benchmark results should be independent of the servlet itself...often
times a literal string is all that needs to be served).  So, Squeak/Kom
is sub-standard because it produces:

    >1ms response time under _no_ load (7-10 ms "out of the box")

    <300 requests per second max (approx 200 requests/s "out of the box")

Each of the comparison server technologies was capable of responding sub
millisecond even under loads which correspond to Kom's maximum.  Each of
the comparison server technologies could handle over 300 requests per
second and in most cases well beyond that.  The net effect (IN MY
OPINION) is that Squeak web servers feel noticably sluggish even under
no load.  Most people I've talked to say the same thing.  I've heard
claims about "saturating a 10Mb/s network"...let me just say that under
load with the current VM latency has a much larger effect on
responsiveness and robustness than throughput.

>Yes, I noticed a while back. Whenever you feel you have any changes for
>the Kom codebase, let me know.
>  
>
I will.  First the VM needs to be fixed:  The file I/O model under Linux
and Windows needs to be made so as to not block the VM (including "stat"
calls -- I think I/O threads is the only way to get non-blocking
stat-type operations).  Socket I/O under Linux needs to move to a I/O
pump thread and away from the AIO library.  Obviosly these could produce
a unified I/O model (socket and file I/O).  I know there are people
smarter than me working on this though.

What I have right now are:

    1) a VM hack which improves the latency under Linux (still around
1ms under no load) by tuning the polling interval (it's on the web page)
    2) an asynchronous I/O version of ModFile which is platform dependent

I don't see #2 becoming part of Kom unless I can make it platform
independent.  It suits my purposes though...fast file I/O under Linux.

David




More information about the Squeak-dev mailing list