httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nitin Sonawane <nsonaw...@infolibria.com>
Subject Re: select vs. threads vs. fork
Date Mon, 19 Apr 1999 21:56:55 GMT
unknown@riverstyx.net 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.


Youre right that network/socket i/o is implicitly non-blocking (thank
TCP for its window buffers). The issue Im unconvinced of is file system
calls. Those can indeterminately block inside the kernel (unless your
htdocs tree sits in your buffer cache). Inodes can be written
asynchronously (eg., last access time stamps) but cannot be read
asynchronously. Consequently all file system calls could get serialized
inside the kernel. Its these calls that would end up throttling
performance.

As a ball park estimate consider a 10ms delay for every file open (very
conservatively spread across inode reads and or directory reads), you
couldnt possibly serve more than 100 static files per second.

The second issue I dont understand is 'unnecessary context switches'.
Isnt it the case that the kernel is incessantly servicing peripheral
interrupts. If so wouldnt context switches be almost unavoidable? 

Speaking of mit-pthreads, barring some overhead wouldnt such a server
internally behave in the same manner as a select/poll based system. If
yes, then we should be able to compile apache-apr with mit-pthreads and
see how that performs in terms of sheer throughput.

I dont mean to get into a flame war but rather a brainstorming of 'why
would event driven servers ever perform better than a
multiprocess/threaded server'. 

Cheers,
Nitin.

Mime
View raw message