> Perhaps the performance different between web servers is more a
> reflection on the Apache than the underlying technique. Having written
> and maintained an Apache module for a decade, I must confess that is not

> my favorite piece of code...

True. It's name - "a patchy server" - was well deserved, even when the
code base was still young. As always, 'good enough' code arriving at the
right time gets ahead and even in open source it tends to be a 'winner
takes all' type of process.

> True, non-blocking IO does not equate to a single thread. But in a
> multi-thread environment, many of the performance benefits of an event
> drive loop go away, and the application begins to look like fine grain
> multi-threading, with the concomitant cost in thread synchronization and

> context switches. I'm not arguing that fine grain multi-thread is not
> the way to go (Stonebreaker disagrees), just that multi-threading is
> more or less multi-threading.

A recent post on high scalability is interesting in this area. Push
services in mobile rely on maintaining many long lived connections with
little data going through (web sockets will change this, but for now its
long-polling). A service may have millions of waiting sockets. It turns out
that a current 64 bit machine can handle 500K simultaneous sockets using
non-blocking io and a callback/queuing event loop:
http://blog.urbanairship.com/blog/2010/09/29/linux-kernel-tuning-for-c500k/

Interestingly, in a seperate blog post it is mentioned that using simple
tools (the Python "eventlets" non-blocking io + cooperative multi-threading
library written by Linden Labs for Second Life), they could operate well
over 30K sockets on a 32-bit amazon 'small' instance.

>> The question now is "how is this relevant to rdbms design?".

Maybe it is all relevant for rdbms's driving mobile apps, with potentially
millions of simple, short-lived transactions coming in from the field. Even
then, I don't think we'll be in the 500K per machine range, as that can
only be done for sockets that are mostly idle and hence require very little
CPU.

Paul