httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: Performance fix in event mpm
Date Thu, 27 Jan 2011 18:43:19 GMT

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
>> Please let me know if you think this change is appropriate and/or if you'd like more
> 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...
View raw message