Re: InfoWorld web server shootout

Dean Gaudet (dgaudet-list-linux-kernel@arctic.org)
Mon, 7 Jul 1997 20:39:04 -0700 (PDT)


On Mon, 7 Jul 1997, Michael Nelson wrote:

> >However I have doubts that at the top end Apache actually keeps up with
> >the netscape and microsoft servers. There are various reasons for this,
> >including the fact that most people have less than 10Mbits to fill, and
> >it's very easy to fill that, so it's never been a priority. I have plans
> >for the top end, the new development tree has improvements in it
> >already...
>
> One advantage (?) that NT has is the fact that it can throw files out to a
> socket without any user-mode/kernel-mode transitions (and buffer copying)
> using the TransmitFile APIs. IIS running in a single process probably
> doesn't hurt either.

First of all, threading. Naively threading apache is not going to be a
win on linux. Tell me if I'm wrong: thread creation and process creation
speeds are about the same. Additionally, there's no huge memory savings
to be had -- I see about 80k to 100k unshared data per httpd-child on
a server with hundreds of children serving millions of hits per day.
This is essentially only the request-specific data, plus a few other
unshared pages.

Another fun NT optimization is the whole WaitForCompletion() thing,
which is like select() on steroids. This is where the big threading
wins come in. WaitForCompletion has the semantic that when an i/o
event happens it wakes up exactly one thread and hands it the event.
Whereas select() has the semantic that it wakes up all threads and they
fight to see who gets to deal with the event. Not only that, NT will
wake up the most-recently awake thread which increases cache-coolness.
To utilize this in the Apache programming model would require a user
level threads package layered on top of kernel threads.

Unix can do almost the equivalent of TransmitFile using mmap(). You have
open/mmap/write instead of open/TransmitFile. So to see winnings of
TransmitFile, open/mmap once and cache the sucker.

Threaded apache is some unknown time away, so I've been trying to
figure out how to dynamically build (and adapt) an open/mmapped file
cache in a multiprocess server. Brilliant ideas welcome. Oh yeah,
you can assume that it's relatively cheap, and definately safe for the
parent to blow away hundreds of children and respawn them occasionally.
It can even do that without interrupting a hit in progress.

The NT port in 1.3-dev is multithreaded, and went in relatively easily.
It hasn't been stressed at all though, and hasn't been optimized.
Look for an alpha/beta in a month or so. Threaded apache on unix
won't happen for a while, we're hoping to learn from the NT experience.
There are other arguments for delaying threaded unix code... in particular
the severe lack of third party libraries that support threading (such
as dns, various database libraries, perl).

Dean