httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael H. Voase" <>
Subject Re: More on early multiplexing.
Date Thu, 11 Mar 1999 14:41:25 GMT
Michael H. Voase wrote:
> Gday ,
>         Listening to the strategy council on accept methods ,
> I have a fairly simple concept that I want to throw into the
> debate for your perusal .
>         The concept involes a queue much like Ryan's descriptor
> queue but instead of an acceptor loop feeding client sockets to
> waiting worker threads , the queue holds the server sockets that
> are grabbed off the queue by the threads which then block on the
> accept to the socket . Heres a little picture of me concept :-
> blocked threads --> (server socket queue )  <---------------------
> ^                               |                                 |
> |                               V                                 |
> |                        thread blocked on accept on socket X     |
> |                               |                                 |
> |                               V                                 |
> |                        Unblocked by a request the thread -------
> |                        enqueues server socket back onto queue
> |                         wanders off with the client socket to
> |                        service request
> |                               |
> |                               V
> L_______________________ Thread completes the request
>                          and rejoins queue for the next
>                          server socket
>         The (hopeful) outcome of the scenario is that
> there are as many threads as there are sockets waiting
> on an accept directly without needing to select on a group of
> sockets . Also if there are more sockets than threads then
> theoretically a thread will probably never sleep whilst
> grabbing the next socket off the queue and if there are more
> threads than sockets then the threads block on the mutex
> around the queue . However in this scenario , all the
> sockets have a thread accepting on the socket directly instead
> of having a select on multiple descriptors ...
> This also avoid the rather nasty situation of a fast acceptor
> thread hogging a queue .
> Cheers Mik Voase.
	Addendum to me previous message -

	I would also like to add that the server socket queue
system does not have to be limited to a single queue . Multiple 
queues' can be implemented to tailor the response of an installed
server to to optimize the response vs memory consumption of the 
server . If one uses an accept wrapper that is configurable by the
Apache server config files , then one could configure a set of
server sockets to be handled by a particular queue . If an additional
arguement is provided to the directive that specified the <I> type </I>
of queue , then the administrator can specify wheter it is a direct
( block on accept ) or a select (block on select of many descriptors )
type of queue .

	The trick is to leave the existing classic 'all on accept
mutex' in there and augment it with a server socket queue .

	If one has a particularly active set of sockets that are
frequently used then one can allocate those services to a given queue
with process counts to suit ( geez you could probably implement an 
independent memory pool to go with it ;-). If it is a collection of 
slower response sockets then a few processes can be used to service 
those sockets on a collective basis. . This way a site admin can have 
ultimate control of a sites' performance . 

(more fuel for the fire)

Cheers Mik Voase

 /~\     /~\            CASTLE INDUSTRIES PTY. LTD.
 | |_____| |            Incorporated 1969. in N.S.W., Australia
 |         |            Phone +612 6562 1345 Fax +612 6567 1449
 |   /~\   |            Web
 |   [ ]   |            Michael H. Voase.  Director.
~~~~~~~~~~~~~~          The only difference between a car salesman and
a computer salesman is that the car salesman knows he's lying .

View raw message