On Fri, 28 Jan 2011, Jim Jagielski wrote:
I was going to submit it as a backport, yes.
I have a strong feeling that this can explain the weird performance
issues/behavior we've seen when hitting any bottleneck that results in
requests being queued up.
Thanks for finding/fixing this :)
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:j...@jagunet.com]
Sent: Thursday, January 27, 2011 12:43 PM
To: dev@httpd.apache.org
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...
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | ni...@acc.umu.se
---------------------------------------------------------------------------
I am Bashir on Borg: I'd be hostile to if my poop was cubed!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
