httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: select vs. threads vs. fork
Date Mon, 19 Apr 1999 21:24:25 GMT

On Mon, 19 Apr 1999 wrote:

> Well, when it's select based you can do your own "task management" meaning
> no unnecessary context switches.  Not that there's much task management to
> do.  Two selects and two for loops to feed all the outputs and read all
> the inputs.  Even in a pre-forked or threaded server, system calls will
> block you.  However, that shouldn't impact much on the throughput, because
> all your I/O is buffered.  It's not as if when you're busy looking for a
> file your TCP output queues are empty and waiting for input.  CGI's are
> forked, so that shouldn't be a problem.

There's a difference between socket i/o and disk i/o.  Socket i/o has
portable non-blocking interfaces which are available end to end -- from
socket creation to close.  Disk i/o has no such portable interface.  When
you call open() you (might) block.  It's even worse on NFS where an open() 
could result in a half dozen network round trips.  When you call read() 
you block (round trips on NFS). 

POSIX defines asynchronous i/o -- aio_read() and such.  But it's not
portable.  And in some places (linux for example) it's implemented via
threads anyhow.

> Plus, the fact that your memory footprint will be much smaller in a single
> process (I'm looking at footprints of 18 megs, including all the mmap'd
> files that most of the select'ing servers I've seen automatically mmap...
> Compare that to an equivalently loaded forked or threaded server.  Still
> in the 200+ meg range on a forked server, and I haven't tried out a
> threaded server on quite that much traffic.  Even still, on a moderately
> loaded threaded server (a snapshot of apache-apr) it's using 90+ megs.

Uh are you just totalling up the SZ column?  That's wrong.  Find the
amount of shared pages.  I've tuned simple static content servers on linux
which consume 80kb *per child* plus some minimum 5 or 6Mb overhead. That's
nothing.  We're not going to do a lot better with threads. 

> That alone is going to harm performance by reducing the total amount of
> memory available for disk caching.

No, you see you're getting into the callback versus thread debate.  The
callback group jumps up and shouts "you've got too many stacks in threaded
programming".  The threaded group jumps up and shouts "you have too many
state structures, they're just as expensive as stacks!  And worse, your
callbacks mess up compiler optimizations!"  They're both right, they're
both wrong. 

All I know is that it's easier for people to think and code linearly, and
the threaded model is far closer to linear than the callback model. 


View raw message