httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <man...@raleigh.ibm.com>
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
similar. 

> 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.

Manoj

Mime
View raw message