Messages in this thread | | | Date | Mon, 7 Jul 1997 22:37:59 -0700 (PDT) | From | Dean Gaudet <> | Subject | RE: InfoWorld web server shootout |
| |
On Mon, 7 Jul 1997, Michael Nelson wrote: > Thread/process creation speed shouldn't matter since Apache is pre-forked, > true? With pre-forking, how are incoming HTTP requests dispatched to > the "child" servers?
You would want to pre-create (or at least re-use) threads so that you don't pay the creation costs on each request. So the relative costs are the same.
The children all use accept() to pick up requests. Actually for many reasons they synchronize at this point before calling accept. Essentially only one child is ever in accept() at any point in time. The details vary from architecture to architecture. It may seem stupid to synchronize, the OS should do it for you in accept, but experience has shown us this solves many a problem. (Without synchronization there are race conditions, starvation problems when multiple Listens are in use, and load-spiking because of select()'s "wake everyone" semantic.)
> >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. > > I'm missing something -- how do you skip read()'ing the file?
It's "read" via mmap. i.e. it isn't ever read() in userland. The kernel just maps it into your memory image and you issue a huge write on it. You have to pay for the mapping though, which is why you want to cache it and use it more than once.
Dean
| |