httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: fix for hybrid server problems.
Date Sun, 09 May 1999 20:54:58 GMT
On Sun, 9 May 1999, Manoj Kasichainula wrote:

> My understanding is that a select()-based server is fast because you
> don't have to deal with many context switches, right?

s/is/can be/

> In this case though, we have at least 1 forced context switch for
> every connection (to pass a new connection to a worker thread). And
> for the slightly big files, we have to jump back to the event thread
> and back again to a worker thread for logging.
> With long files, you avoid the context switching between threads as
> they write out the data, but couldn't this be largely eliminated with
> mmap+write or sendfile() anyway?

I care less about static benchmark tests on local networks with no latency
than I do about real life web sites with loads of long haul, slow clients,
downloading large files consuming an expensive resource:  a thread slot
and stack.

It's one of those cases where my opinion is that the wins are in
real-world useability, and correctness (so far it looks like the best
solution for the graceful stuff) and the cost might be a modicum of
performance loss on static localnet benchmarks. 

Also, this helps keep-alive connections.  We could plop connections back
up to the event-thread to wait for any more input... rather than consuming
a thread for 15s...

We can make the cutoff point different if you're concerned over the extra
context switches... but really -- for responses over SO_SNDBUF, the worker
thread has to block at least once.  It may as well pass the work to the
event-thread to be aggregated with other similar work before blocking. 

What would be extra cool would be LIFO semantics on threads trying to
dequeue from the request queue -- if we could service multiple requests in
one time slice on one thread that would be way nice.

So far my largest concern, which is the same as my concern with entirely
select-based servers, is disk i/o.  This all works wonderfully if you
rarely have to page from disk.  But for servers with large working sets,
aggregating like this hurts because you have only a single i/o request
outstanding at a time... with multiple processes we alleviate some of this
problem... there are probably other options -- but I think this is
something we can deal with when we get there. 


View raw message