Rose, Billy wrote: >If I could receive feedback on the following email made on the 11th, I'd be >willing to burn some hours to make the following MPM for testing: > >>I hope my emails are not annoying you guys. To give a more complete picture >>of this (pulled from methods I used in a client server app): >> >>The initial process creates a shared memory area for the queue and then a >>new thread, or child process, whose sole purpose is to dispatch connections >>to workers. The shared memory area is a FIFO for queuing up connections. >>The dispatcher process then goes on to set up the other children each of which >>has access to the shared memory so they may get at the connection FIFO. The >>FIFO is a linked list containing connection objects that get filled in by >>the listener thread/process. The dispatcher maintains a list of all children >>workers that it created, and sits in a loop sleeping with some set timeout. >>When the listener accepts a connection and puts it in the queue, it wakes >>the dispatcher if need be. Once awakened, the dispatcher looks to see if >>connections are queued, and if so, it looks in its worker list for the next >>available worker and awakens it. >>
I can think of a few factors that will complicate the implementation of this design: * The role of the dispatcher in this design adds some extra context switching to the critical path for accepting a connection. By my count, three or four separate threads--distributed among two or three separate processes--will have to get involved to accept each new connection. Based on the relative performance of the other MPM designs, I'd say that MPMs that involve fewer threads per connection generally are fastest (that's part of why prefork has outperformed the original worker design.) * When the dispatcher looks for an available worker, is it looking for a worker process, or for a worker thread within one of the worker processes? If the dispatcher wakes up a worker process, then that process will need to figure out which of its threads will handle the connection. To do this, it will need to either: 1) let its idle threads take turns handling connections (meaning that it looks a lot like leader/follower) or 2) have one dedicated thread that delegates the connection to an idle worker (meaning that it looks a lot like the threadpool MPM or the original worker MPM). Alternately, if the dispatcher wakes up a worker thread directly, it needs a means to signal a specific thread within another process. It may be very difficult to do that portably. I suppose each idle worker thread could do a blocking read on a separate socket or pipe, and the dispatcher could write a byte to the one that it wants to wake up. But that would slow down connection processing and use up lots of file descriptors. >> The worker then locks the FIFO head pointer >>and grabs the connection, moves the pointer to the next FIFO node, and then >>unlocks the FIFO head pointer. If no workers are available, the dispatcher >>creates more workers if not at a set maximum in order to take the >>connection. If at the maximum, it sleeps again with a shorter timeout, which >>when woke up again, checks for an available worker again. This repeats >>until a worker is available. The listener in all of this is totally independent of >the workers, and only knows that it accepts connections and puts them in a >>FIFO, and finally notifies the dispatcher of the connection. The connection >>queue could span thousands of queued connections if desired. The dispatcher >>is responsible for coordinating the workers, and the queue resides in one >>place only, that being the shared memory segment. >> Having a single queue definitely is the right solution. The catch is that managing that single queue within the httpd is tricky (based on the issues noted above). The alternate way to get a single-queue solution is to let the OS manage the queue for us, which is what the prefork, leader/follower, and threadpool MPMs do. >>Is this too drastic an alteration to the current worker mpm, i.e. would it >>be a separate mpm if it came to fruition? >> Separate MPM --Brian
