httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <>
Subject Re: pass off sending to select loop?
Date Tue, 06 Jan 1998 15:51:17 GMT
On Mon, 5 Jan 1998, Rob Hartill wrote:

> On Mon, 5 Jan 1998, Brian Behlendorf wrote:
> > At 10:23 PM 1/4/98 -0700, Marc Slemko wrote:
> > >Has anyone looked at passing off connections to a seperate process via
> > >descriptor passing, then that processes multiplexes sending for however
> > >many descriptors you want?
> > 
> > Isn't this what they tried to do in NCSA 1.4?  I seem to remember someone
> > from there saying they gave up on that idea due to excessive overhead.
> I don't know if Marc is suggesting the same thing but the NCSA 1.4
> descriptor passing model was a bottleneck on requests. If each request
> involves two separate processes then there's additional overhead there.
> If one of the processes has to handle all incoming requests and farm them
> out then all it is doing is reproducing the mutex/accept sequence that
> currently only involves one child process per request and the kernel
> to pick the next process to run.
> This is how I see incoming requests on NCSA 1.4 and Apache 1.x
> Apache
> r1 ------- [child 1]
> r2 ------- [child 2]
> r3 ------- [child 3]
> r4 ------- [child 4]
> r1 ---\                /--- [child 1]
> r2 ----\__ [parent] __/---- [child 2]
> r3 ----/              \---- [child 3]
> r4 ---/                \--- [child 4]
> I just don't see any reason to stick a process in there. It has to
> slow things down and it also leaves you with all your eggs in one
> basket - the parent process which is now doing a lot more work and
> this increases the likelyhood of catastrophic failure caused by a parent
> process hiccup.
For Solaris 2.4, BSD 2.2.1 and OS/F I can back that with numbers; it seems
some 18% slower; apart from an IMHO worse asemetric pattern with things
like swap involved and a sinlge point of bang.

However a single select()/poll() type loop; followed by cached uri
and auth translation prior to handling it of to more speciazed children
might be an option.

An area of improvement could be the exact mapping/ordering in which the
childs actually accept the new connects. By playing with a few sleeps
prior to listeing again I found that on a loaded server one could keep
a few processes busy while the others where dormant versus the situation
where they all got an more or less equal share. Unfortunately on Solaris
and BSD the strategeies needed to be opposite; and where on the order of
a few percents.


View raw message