I was going to submit it as a backport, yes. On Jan 27, 2011, at 9:08 PM, David Dabbs wrote:
> I see that the changes described below were applied to the trunk worker and > event MPM code. > Would you consider applying it to the 2.2x branch? I will do so myself and > test in my env. > > > Many thanks, > > David Dabbs > > > > -----Original Message----- > From: Jim Jagielski [mailto:[email protected]] > Sent: Thursday, January 27, 2011 12:43 PM > To: [email protected] > Subject: Re: Performance fix in event mpm > > > On Jan 27, 2011, at 1:31 PM, Jim Jagielski wrote: > >> >> On Jan 27, 2011, at 12:21 PM, Jim Van Fleet wrote: >> >>> I have been developing an application using apache 2.2 on linux 2.6. My > test environment creates a very heavy workload and puts a strain on every > thing. >>> >>> I would get good performance for a while and as the load ramped up, > performance would quickly get very bad. Erratically, transactions would > finish quickly or take a very long time -- tcpdump analysis showed > millisecond or seconds between responses. Also, the recv queue got very > large. >>> >>> I noticed that ap_queue_pop removes elements from the queue LIFO rather > than FIFO. Also noticed that apr_queue_pop uses a different technique which > is not too expensive and is fifo, so I changed ap_queue/pop/push to use that > technique and the receive problems went away. >>> >>> Please let me know if you think this change is appropriate and/or if > you'd like more data >>> >> >> Hmmm.... Not sure why the fdqueue would be LIFO. But certainly >> the above ain't right for pop! :) > > OK, looking over the history, it looks like the Q was changed from > FIFO to LIFO ~10years ago (worker)... The reasoning: > > This is a rather simple patch that may improve cache-hit performance > under some conditions by changing the queue of available worker threads > from FIFO to LIFO. It also adds a tiny reduction in the arithmetic that > happens in the critical section, which will definately help if you have > a lame compiler. > > Seems to me that changing back to FIFO would make sense, esp > with trunk. We can profile the expense of the '% queue->bounds' > but it seems to me that if it was really bad, we'd have seen it > in apr and changed it there... after all, all we're doing > with that is keeping it in bounds and a comparison and subtraction > would do that just as well... >
