httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Dabbs" <>
Subject RE: Performance fix in event mpm
Date Fri, 28 Jan 2011 02:08:49 GMT
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 [] 
Sent: Thursday, January 27, 2011 12:43 PM
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
>> 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
>> 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...

View raw message