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.

Cheers,
   - Andreas