> > From: Aaron Bannert [mailto:[EMAIL PROTECTED]] > > > > On Thu, Apr 25, 2002 at 11:30:54AM -0400, Bill Stoddard wrote: > > > Would someone care to see if this fixes the worker MPM performance > > problem reported > > > earlier on the list (request-per-second dropping when clients > exceeded > > threadsperchild)? > > > This patch defers starting the listener untill -all- the workers > have > > started. > > > > I'm not really sure how this would fix the performance problems, and > given > > the current theory it might even exacerbate it. The current hypothesis > > is that when we run out of available workers in all available > children, > > and we are waiting for a new child to be spawned, connections continue > > to be accepted and placed in a queue*, and as such aren't able to be > > immediately serviced as soon as the new child is started. > > > > A simple fix would be to prevent the queue* from accepting more > > connections until there is an idle worker thread available. The reason > > I have hesitated to make this change is because it would alter the > > places where the listener thread may enter blocking calls, and would > > probably break graceful/non-graceful restarts. If I get a little > > time I will try to look in to this again this weekend. > > > > * When I say "queue" I really mean stack. In thinking about this > problem > > over the last few days I realized that we should convert back to a > true > > LIFO, otherwise it is possible for a request to sit at the back of the > > stack for a long time before it is serviced. > > I hope you mean FIFO here. If you use a LIFO, then the first request > received will be the last request served, which is a bad thing. > > Ryan >
I think he is referring to the order the threads are dispatched. Ideally you want the last active thread to get the next work (ie, LIFO dispatching). Bill
