httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: More on early multiplexing.
Date Tue, 30 Mar 1999 09:02:29 GMT
On Mon, Mar 29, 1999 at 04:56:09PM +0000, Michael H. Voase wrote:
> 	the server socket queue would have the same essential characteristics
> that allows acceptor loop to perform well on THS crippled servers .
> However 
> it retains a more traditional code structure . 

Actually, I don't think that the code structure of the connection
queue model (Ryan's idea), the server socket queue (your idea), and
the select-accept model are that different at a high level, at least
the way I think of it.

In all models, the threads doing all the work go through a process of
getting a request from somewhere and then dealing with it. In Ryan's
model, you have acceptor threads "prefetching" connections for the
worker threads, but I think if you take out the acceptor threads from
Ryan's model, the code paths in Ryan's model and yours should be very

> Ryan Bloom wrote:
> > The two synchronization points doesn't concern me.  The current fdqueue
> > implementation has two points of synchronization(1 in and 1 out), and it
> > is very fast.

Actually it has three points in the current implementation (1 in, 2
out) not counting the points of accept serialization. But it's still
pretty fast.

> 	Lastly as a note to this concept , I have doubts as to whether
> this algorithm ( or Ryan's for that matter ) could beat the classic 
> accept method that is tried and tested on machines that don't suffer 
> from THS . The server socket queue does have a small advantage that it 
> does not need select() to detect an incoming request , but that would 
> probably be offset by the added overhead of the queue .

One thing we want to do is to benchmark the different accept models
against each other. It's the only way to say with any confidence which
model is faster.

> 	One interesting ramification in this algorithms
> favour is that it does give a logical 'separation' point for
> servers of mixed builds .
> 	With a server socket queue layout one could allocate 
> each build set to a process with its own queue , declare what
> port(s) each process would be listening to and allocate the 
> number of threads to suit . This could be made optional with
> the all-on-accept method ready to use instead , with each process
> being allocated its build type then its sockets . Since 
> the classic method could accept on multiple sockets , it would
> be trivial to implement it as the default with each process having its
> own mutex and FDSET . Further more , this conceptualisation can 
> contribute back to the core code base by formalising a definition
> for mixed build servers with individual mutexes . Being able to 
> configure a mix of builds in one config file could be of some 
> benefit to web masters . no ?

This can all be done with any accept model. The important piece here
is giving a different configuration and list of file descriptors to
each child process. This piece doesn't change when the accept model
changes. I think the real work needed to get something like this
working is in the configuration engine and (the hard part) in managing
the different pools of processes.


View raw message