Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of trawick@gmail.com designates
 209.85.214.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAHSOX_C4nSHLnCjUW8pypLoX0iEX=9DcagUOnqY6MeNtt+kHqQ@mail.gmail.com>
References: <20111115155104.39CA1238897F@eris.apache.org>
	<CAHSOX_C4nSHLnCjUW8pypLoX0iEX=9DcagUOnqY6MeNtt+kHqQ@mail.gmail.com>
Date: Fri, 18 Nov 2011 15:48:34 -0500
Message-ID: 
 <CAKUrXK6xacfZ=rED52z3oy-6wxP=nU8QcvLfF8=DFVEoiL5A7Q@mail.gmail.com>
Subject: Re: svn commit: r1202257 - in /httpd/httpd/trunk/server/mpm/event:
 config3.m4 equeue.c equeue.h event.c
From: Jeff Trawick <trawick@gmail.com>
To: dev@httpd.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 18, 2011 at 2:43 PM, Greg Ames <ames.greg@gmail.com> wrote:
>
>
> On Tue, Nov 15, 2011 at 10:51 AM, <pquerna@apache.org> wrote:
>>
>> Log:
>> Create a new lock free circular queue, and use it in the EventMPM to
>> remove the timeout mutex that was wrapping both timeout queue operations=
 and
>> pollset operations.
>>
>> @@ -1632,6 +1672,20 @@ static void * APR_THREAD_FUNC listener_t
>> =A0 =A0 =A0 =A0 =A0 =A0 num--;
>> =A0 =A0 =A0 =A0 } =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* while for proce=
ssing poll */
>>
>> + =A0 =A0 =A0 =A0{
>> + =A0 =A0 =A0 =A0 =A0 =A0/* TODO: break out to separate function */
>> + =A0 =A0 =A0 =A0 =A0 =A0int i;
>> +
>> + =A0 =A0 =A0 =A0 =A0 =A0for (i =3D 0; i < threads_per_child; i++) {
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ap_equeue_t *eq =3D worker_equeues[i];
>>
>
> I am concerned that the performance cost of touching (threads_per_child)
> pieces of memory on every trip thru the listener loop plus an additional
> context switch for every apr_pollset_add() might be more than the savings
> from getting rid of occasional mutex contention.=A0 so I tried some simpl=
e
> benchmarks.=A0 If I measure the throughput of a single keepalive connecti=
on,
>
> $ bin/ab -k -c 1 -n 1000 localhost/index.html
> ...
> Requests per second:=A0=A0=A0 10.18 [#/sec] (mean)
>
> it looks broken.=A0 I am guessing that the new apr_pollset_wakeup() calls=
 are
> not working as intended. the event pollset timeout_interval is 100 msec, =
so
> that's what is giving us 10/sec.

Try this:

Index: server/mpm/event/event.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- server/mpm/event/event.c	(revision 1203816)
+++ server/mpm/event/event.c	(working copy)
@@ -1483,9 +1483,9 @@
         rc =3D apr_pollset_poll(event_pollset, timeout_interval, &num, &ou=
t_pfd);
         if (rc !=3D APR_SUCCESS) {
             if (APR_STATUS_IS_EINTR(rc)) {
-                continue;
+              /* continue; */
             }
-            if (!APR_STATUS_IS_TIMEUP(rc)) {
+            else if (!APR_STATUS_IS_TIMEUP(rc)) {
                 ap_log_error(APLOG_MARK, APLOG_CRIT, rc, ap_server_conf,
                              "apr_pollset_poll failed.  Attempting to "
                              "shutdown process gracefully");

As I read the docs, we get APR_EINTR back if apr_pollset_wakeup() was calle=
d.
(It seems to fix it for me from an ab standpoint, but I haven't looked
in detail.)


> 2.4's Event, same ab invocation:
>
> Requests per second:=A0=A0=A0 9410.79 [#/sec] (mean)
>
> worker from trunk:
>
> Requests per second:=A0=A0=A0 10401.39 [#/sec] (mean)
>
> Greg
>
> p.s. this is on my ThinkPad W520 with 32 bit Linux Ubuntu natty
>


--=20
Born in Roswell... married an alien...