HTTP server choices?
andreas.raab at gmx.de
Wed Jan 4 18:09:04 UTC 2006
David Shaffer wrote:
> 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.
Has anyone ever thoroughly benchmarked this? There are certainly
platform differences but it seems like having an acceptable benchmark
suite would make finding hot spots much easier.
>>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).
It's actually not quite so obvious. One issue (that I learned over time)
is that you really don't want to use native threads (at least not
without thread pooling) since the creation of those threads is to
heavy-weight. Like, right now creating a socket (Socket new) takes
almost a millisecond and most of this is in setting up two new threads
(never mind that this also takes significant resources which further
limits the max throughput). Try this for example:
[1 to: 100 do:[:i| Socket new destroy]] timeToRun
This gives you a feel for what basically "unavoidable overhead" is
(creating and destroying a socket) and unless I'm mistaken it will show
quite clearly why you can't possible get sub-millisecond response on
Windows (dunno about other platforms but on Win32 this takes about 2ms
per socket - which I believe is exclusively due to dealing with threads).
> 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
For #2 are you aware that there's AsyncFile for asynchronous I/O access?
This may actually give you a cross-platform solution.
More information about the Squeak-dev