httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: select vs. threads vs. fork
Date Tue, 20 Apr 1999 07:00:29 GMT

tani hosokawa
river styx internet

On Mon, 19 Apr 1999, Dean Gaudet wrote:

> On Mon, 19 Apr 1999 wrote:
> > My argument is, they don't matter.  For a normal static content servers,
> > most data is cached since it's used over and over.  Checking vmstat, it's
> > normal to see at most 40 blocks being read in per second.
> localdisk.  Try it on NFS. 
> > Like I said before, you're not likely to be in a situation where you never
> > serve the same file twice.  I can easily serve move than 100 static files
> > per second with Apache.  I can easily serve more with a different server.
> I've had specweb results for apache on linux in the 1500 range quoted to
> me.
> 100/s is trivial, I can't imagine how you're not serving more than that.
> At any rate -- does your 100/s saturate your CPU?  Does it saturate your
> internet pipe?
> I find it hard to get excited about benchmark numbers on locally attached
> gigabit networks when the internet pipe is still so small.  It doesn't
> take much to saturate the bandwidth a server has available. 

Actually, it generally just runs out of memory.  But beyond that, the load
average also gets way up there.  Like, 12-15.  According to top, the CPU
is only at 20-25% utilization at this point... network bandwidth probably
isn't an issue, since it's on ethernet and the server's nowhere near
filling that.  Switched ethernet, with burstable 100Mb available (minus
the other servers).  The most I've gotten it up to is about 0.8 MB/sec.

> > This isn't exactly an event driven server model.
> I think the piece your missing is an understanding of the difference
> between a userland threads package (such as mit-pthreads) and a kernel
> threads package (such as linuxthreads), and hybrids of the two (such as
> solaris pthreads, or NSPR).
> Maybe this can sum it up:  assume that you can wrap all the socket library
> calls, socket(), connect(), read(), write(), ...  For each socket created
> you place it in non-blocking mode.  Then when a read() or a write() would
> block, you can stop doing what the caller asked, and you can start doing
> something else (longjmp() somewhere else).  Somewhere along the way you do
> a select() and find out that the socket is ready for more i/o.  Then you
> can switch back to the fellow blocked in read() and complete the
> operation. 
> That's userland threads:  behind the scenes all your i/o operations are
> translated into select() operations. 
> Sounds a lot like select/event doesn't it? 
> The difference is in where you keep track of context.  In
> select/event/callback you keep track of it explicitly in data structures.
> In userland threads you keep track of it on a stack.

Hmm.  I've only worked with Linuxthreads, so I'm probably missing a good
chunk of the picture.

View raw message