You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by bh...@pobox.com on 1999/03/10 16:49:56 UTC
More on early multiplexing.
Bill Stoddard writes:
> BTW, using apache-apr, I did some informal comparisons between the
> accept queue model (one thread per socket doing an accept and queuing
> the descriptor to be consumed by a pool of worker threads) and the
> multi-accept model (all worker threads blocked on a mutex. one allowed
> in to do a select/accept.) I implemented the multi-accept to bypass
> doing the select if only listening to one socket. I was suprised to
> find that there was less that 1% difference in connections per second
> between the two. (using ApacheBench w/o keep alive fetching a 500 byte
> file). The multi-accept case was slightly faster (and a lot simpler).
The queue/mutex/threads are entirely use space right? So no OS context
switchs? Performance wise I'd be surprised if you could measure the
difference at all.
The funnelling of all incomming requests thru a single or a few
queues is analagous to the "early multiplex" idea. I.e. the
senario were something is responsible for getting requests
into the approprate rights and process model.
There are a few reasons that an early multiplex scam maybe
a good idea.
- Apache modules that are not thread safe want to run in a
a private process. They may not be easily converted sine
they are dependent on yet other things.
- ISP customer modules want to go in to their own process
for protection reasons.
- The early multiplex would make a fine kernel module
(possibly plus the default serve from file system/cache module)
- It's complex and fresh and there for interesting (opps
that is not a good thing).
|-> threaded apache + modules
clients<-http->EarlyMultiplexer<-|-> classic apache + modules
|-> user_foo space apache + modules
|-> ...
While this doesn't require implementing the classic apache API on that
bus. Only enough lexical analysis of the incomming requests to to the
multiplex is needed in the EarlyMultiplexer (i.e. the handler
binding). That bus still involves a messy tangle of zero copy, shared
memory, a replacement for buff.c and delicate cross process
multiplexing. One might declare that bus API private.
It's a drawing certain to fail any KISS testing!
- ben
Re: More on early multiplexing.
Posted by "Michael H. Voase" <mv...@midcoast.com.au>.
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 http://www.midcoast.com.au/~mvoase
| [ ] | Michael H. Voase. Director.
~~~~~~~~~~~~~~ The only difference between a car salesman and
a computer salesman is that the car salesman knows he's lying .
----------------------------------------------------------------------------
Re: More on early multiplexing.
Posted by Manoj Kasichainula <ma...@raleigh.ibm.com>.
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
Re: More on early multiplexing.
Posted by "Michael H. Voase" <mv...@midcoast.com.au>.
Ryan Bloom wrote:
>
> I am cutting things out because this thread is long, and we really don't
> need to rehash everything.
Yup . likewise ...
> The reason the accept queue algorithm works well on non-THS systems,
> without adding any real complexity, is we use the SAFE_ACCEPT macro. This
> macro will allow multiple accept threads into the accept on non-THS
> systems (This hasn't been coded yet, but it is the end goal, and the code
> has been designed to allow this).
>
Hrrm ... interesting . If one wishes to allow multiple
threads on accept with server-socket loop , then simply
add duplicate sockets to the queue ( you could even
configure how many ...;-) , IFF you are running
on a system that doesn't suffer from THS and can use
SAFE_ACCEPT and has enough threads minimum to cover
all the sockets in the queue ...
Cheers Mik Voase.
PS. Is guest CVS login still permitted at worldgate ?
I tried to do a checkout on the latest APR source and
got a non login . ( yes I RTFM ).
--
----------------------------------------------------------------------------
/~\ /~\ CASTLE INDUSTRIES PTY. LTD.
| |_____| | Incorporated 1969. in N.S.W., Australia
| | Phone +612 6562 1345 Fax +612 6567 1449
| /~\ | Web http://www.midcoast.com.au/~mvoase
| [ ] | Michael H. Voase. Director.
~~~~~~~~~~~~~~ The only difference between a car salesman and
a computer salesman is that the car salesman knows he's lying .
----------------------------------------------------------------------------
Re: More on early multiplexing.
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
I am cutting things out because this thread is long, and we really don't
need to rehash everything.
> > These two cases are at odds with each other, and I am having a hard time
> > resolving it.
>
> Yes they are at odds with each other . Considering that
> there are OS's out there dont suffer from THS and thus can use the
> classic 'all-on-accept' method quite successfully , then there is no
> real need to have a server socket queue or an acceptor loop . Let me
> see ... mmm I remember a message that went something like ...
>
> [snip]
>
> Another solution is to have all threads block on the accept. Then, you
> take the chance of the OS having a problem with a thundering herd. If
> all
> threads block on the accept, and a request comes in, many OS's will wake
> up all of the threads, and then put them back to sleep after the first
> thread has gotten the request. This causes many many context switches.
> BAD :( There is also the potential, out of pure dumb luck, that two
> threads will get through to the accept loop at once (IBM's last web
> server
> had this problem when they used this algorithm), this will cause bad
> things to happen.
>
> [snip]
>
> 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 .
The reason the accept queue algorithm works well on non-THS systems,
without adding any real complexity, is we use the SAFE_ACCEPT macro. This
macro will allow multiple accept threads into the accept on non-THS
systems (This hasn't been coded yet, but it is the end goal, and the code
has been designed to allow this).
Any macro for THS/non-THS systems with the server-socket queue, would have
to alternate between shared and non-shared memory, and this seems like it
would be more complex.
However, we are in the middle of abstracting out the accept logic.
Hopefully, it will be done soon, and then to put in a new accept method,
it will only require defining a couple of functions. We are doing this
because there are so many options in a threaded server, and depending on
what kind of site you are serving, some are much better than others.
As soon as we get it done, I think somebody should implement the
server-socket queue accept model, and we can see what is best. I
personally think that if the server-socket queue is done properly, it will
be either better or as good as the accept queue, but I also think it will
need to be much more complicated to do things correctly on all systems.
> > 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. The testing we have done seems to indicate that one process
> > handles all of the load until it is pegged, and then another process helps
> > out.
>
> Hrrm ... interesting .
As Manoj noted, there are three synchronization points. I purposefully
left the third one out in my comments, because it is in there for
implementation reasons (to close a thread-safety issue), not for design
reasons. And, adding it didn't do anything to our performance if I
remember correctly.
> 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 .
We have done some very basic performance testing. On a single socket
system, without the select call, the accept queue performs 1% slower than
the standard Apache-1.3 algorithm. This could very easily be in the
noise. And, any Apache-1.3 algorithm would require the slect, which would
degrade our performance considerably. Bill Stoddard mentioned this in a
note a while ago.
>
> As Dean points out earlier there is two sync points in server socket
> queue ,
> classic Apache only has one - the accept mutex
>
> 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 ?
>
> Just a couple of thoughts anyways
Not sure I understand some of this. Perhaps seeing a config language
would help me.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: More on early multiplexing.
Posted by "Michael H. Voase" <mv...@midcoast.com.au>.
Gday,
Looking back at me former message , I can see
I should clarify this algorithm a bit ...
( Note - THS in this passage stands for 'thundering heard syndrome' . I
am tired of writing this out fully .. ;-P )
Ryan Bloom wrote:
>
> On Sun, 21 Mar 1999, Dean Gaudet wrote:
>
> >
> >
> > On Thu, 11 Mar 1999, Michael H. Voase wrote:
> >
> > > 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 last bit just above referring to the thread rejoining
a 'queue' just simply means blocking on the mutex around the
the server socket queue . My apologies if this has caused
confusion .
> > I think the main problem with this is that it has two synchronization
> > points -- you have to block on the queue on the way into and the way out
> > of accept.
>
> It has taken me a while to be able to express the concerns I have with
> this algorithm, but I'll give it a try.
>
> There are two cases that should be considered.
>
> 1) An OS with a thundering herd problem, in which case the queue would
> have to go in shared memory, or we need another synchronization point.
> With thundering herd, we want only one thread in the entire server
> listening on the port. By putting the queue in shared mem, we get that.
> If we don't use shared mem, the other synchronization point is so that
> each thread that gets a socket descriptor from it's process's queue has to
> check that the port isn't being listened to by another process.
To clarify what I was suggesting , yes the server socket queue should
( (w|c)ould ? ) be shared only in the threads serving the the port(s)
in the queue . Only one instance of each port being serviced should
be present in the queue loop . If one builds a server such that there
is one queue per process ( with of course multiple threads in that
process ) one could allocate what sockets are to be serviced by that
process . The idea can then be expanded to accomidate different builds
of server . That is , if one wanted a child process built with ,say ,
mod_perl servicing another port , then a distinct build could be used
in its own process with its own queue and have the number of threads
allocated to how much resource you could afford to feed it with ;-)
One of the core advantages of this queue is that it has a
very similar code structure to the 'all on accept' method that Apache
currently uses . The idea being that it should be reasonably possible
to implement the queue along side existing apache code . By allowing
the user to be able to select type of accept method apache is built
with , the code could achieve some flexibility ( equivalent of 1.3.x
style in the same code base ) . I hope that this satisfies Ryans two
conditions that he has pointed out .
Secondly , with THS the server socket queue would have the
same process control qualities that the acceptor loop method already
has . Basically , the acceptor loop uses cond_signal and cond_wait
functions to signal the worker threads .
>
> 2) An OS without a thundering herd problem, in which case, we want as
> many threads as possible listening to a port. This algorithm gives us
> that ability, but each process would need it's own queue.
>
Yes.
> These two cases are at odds with each other, and I am having a hard time
> resolving it.
Yes they are at odds with each other . Considering that
there are OS's out there dont suffer from THS and thus can use the
classic 'all-on-accept' method quite successfully , then there is no
real need to have a server socket queue or an acceptor loop . Let me
see ... mmm I remember a message that went something like ...
[snip]
Another solution is to have all threads block on the accept. Then, you
take the chance of the OS having a problem with a thundering herd. If
all
threads block on the accept, and a request comes in, many OS's will wake
up all of the threads, and then put them back to sleep after the first
thread has gotten the request. This causes many many context switches.
BAD :( There is also the potential, out of pure dumb luck, that two
threads will get through to the accept loop at once (IBM's last web
server
had this problem when they used this algorithm), this will cause bad
things to happen.
[snip]
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 .
>
> 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. The testing we have done seems to indicate that one process
> handles all of the load until it is pegged, and then another process helps
> out.
Hrrm ... interesting .
>
> Ryan
>
> _______________________________________________________________________
> Ryan Bloom rbb@raleigh.ibm.com
> 4205 S Miami Blvd
> RTP, NC 27709 It's a beautiful sight to see good dancers
> doing simple steps. It's a painful sight to
> see beginners doing complicated patterns.
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 .
As Dean points out earlier there is two sync points in server socket
queue ,
classic Apache only has one - the accept mutex
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 ?
Just a couple of thoughts anyways
Cheers Mik Voase.
--
----------------------------------------------------------------------------
/~\ /~\ CASTLE INDUSTRIES PTY. LTD.
| |_____| | Incorporated 1969. in N.S.W., Australia
| | Phone +612 6562 1345 Fax +612 6567 1449
| /~\ | Web http://www.midcoast.com.au/~mvoase
| [ ] | Michael H. Voase. Director.
~~~~~~~~~~~~~~ The only difference between a car salesman and
a computer salesman is that the car salesman knows he's lying .
----------------------------------------------------------------------------
Re: More on early multiplexing.
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
On Sun, 21 Mar 1999, Dean Gaudet wrote:
>
>
> On Thu, 11 Mar 1999, Michael H. Voase wrote:
>
> > 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
>
> I think the main problem with this is that it has two synchronization
> points -- you have to block on the queue on the way into and the way out
> of accept.
It has taken me a while to be able to express the concerns I have with
this algorithm, but I'll give it a try.
There are two cases that should be considered.
1) An OS with a thundering herd problem, in which case the queue would
have to go in shared memory, or we need another synchronization point.
With thundering herd, we want only one thread in the entire server
listening on the port. By putting the queue in shared mem, we get that.
If we don't use shared mem, the other synchronization point is so that
each thread that gets a socket descriptor from it's process's queue has to
check that the port isn't being listened to by another process.
2) An OS without a thundering herd problem, in which case, we want as
many threads as possible listening to a port. This algorithm gives us
that ability, but each process would need it's own queue.
These two cases are at odds with each other, and I am having a hard time
resolving it.
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. The testing we have done seems to indicate that one process
handles all of the load until it is pegged, and then another process helps
out.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: More on early multiplexing.
Posted by Dean Gaudet <dg...@arctic.org>.
On Thu, 11 Mar 1999, Michael H. Voase wrote:
> 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
I think the main problem with this is that it has two synchronization
points -- you have to block on the queue on the way into and the way out
of accept.
Dean
Re: More on early multiplexing.
Posted by "Michael H. Voase" <mv...@midcoast.com.au>.
Gday ,
Listening to the strategy council on accept methods ,
I have a fairly simple concept that I want to throw into the
debate for you 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 .
A major headache could occur if one has a poor
implementation of a thread queue that drops entries for
whatever reason . Also there are possibilities for
starvation problems when low hit rate sockets are mixed
with high demand sockets however if there are enough threads
to soak up slow sockets , then the reamining threads should
be able to handle the traffic . If you have hundreds of
low hit rate sockets being handled by the server then
that would cause a major problem for this model . This
is not good . It occurs when there are more sockets
to service than threads in the server . At its worst
if you have ,say, 20 sockets , 15 with almost non-existant
request count and 5 highly active sockets and a server
with ten threads . Very quickly the threads would
all end up hung on the slow moving sockets causing
hideous starvation problems for the fast sockets .
I leave it up to you lot if this is acceptable or
unacceptable . Im not going to argue it either way
since it would be possible to re-design a site so that
all the slow moving services are on one socket .
However I also acknowledge that site re-design might
not be an option if it is a dogs breakfast to begin
with ....
The performance difference would be hardly noticable on a
server taking requests on a single socket however it would
become more noticable when a server is handling 10+ sockets
with medium to high hit rates . Lastly I believe that this
scenario should also satisfy the KISS rule that Dean keeps
advocating .
Comments ? Opinions ?? Get out the fireproof suit ???
Cheers Mik Voase.
bhyde@pobox.com wrote:
>
> Bill Stoddard writes:
> > BTW, using apache-apr, I did some informal comparisons between the
> > accept queue model (one thread per socket doing an accept and queuing
> > the descriptor to be consumed by a pool of worker threads) and the
> > multi-accept model (all worker threads blocked on a mutex. one allowed
> > in to do a select/accept.) I implemented the multi-accept to bypass
> > doing the select if only listening to one socket. I was suprised to
> > find that there was less that 1% difference in connections per second
> > between the two. (using ApacheBench w/o keep alive fetching a 500 byte
> > file). The multi-accept case was slightly faster (and a lot simpler).
>
> The queue/mutex/threads are entirely use space right? So no OS context
> switchs? Performance wise I'd be surprised if you could measure the
> difference at all.
>
> The funnelling of all incomming requests thru a single or a few
> queues is analagous to the "early multiplex" idea. I.e. the
> senario were something is responsible for getting requests
> into the approprate rights and process model.
>
> There are a few reasons that an early multiplex scam maybe
> a good idea.
> - Apache modules that are not thread safe want to run in a
> a private process. They may not be easily converted sine
> they are dependent on yet other things.
> - ISP customer modules want to go in to their own process
> for protection reasons.
> - The early multiplex would make a fine kernel module
> (possibly plus the default serve from file system/cache module)
> - It's complex and fresh and there for interesting (opps
> that is not a good thing).
>
> |-> threaded apache + modules
> clients<-http->EarlyMultiplexer<-|-> classic apache + modules
> |-> user_foo space apache + modules
> |-> ...
>
> While this doesn't require implementing the classic apache API on that
> bus. Only enough lexical analysis of the incomming requests to to the
> multiplex is needed in the EarlyMultiplexer (i.e. the handler
> binding). That bus still involves a messy tangle of zero copy, shared
> memory, a replacement for buff.c and delicate cross process
> multiplexing. One might declare that bus API private.
>
> It's a drawing certain to fail any KISS testing!
>
> - ben
--
----------------------------------------------------------------------------
/~\ /~\ CASTLE INDUSTRIES PTY. LTD.
| |_____| | Incorporated 1969. in N.S.W., Australia
| | Phone +612 6562 1345 Fax +612 6567 1449
| /~\ | Web http://www.midcoast.com.au/~mvoase
| [ ] | Michael H. Voase. Director.
~~~~~~~~~~~~~~
----------------------------------------------------------------------------