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...
