On Fri, Nov 18, 2011 at 4:06 PM, Greg Ames <[email protected]> wrote: > > > On Fri, Nov 18, 2011 at 3:48 PM, Jeff Trawick <[email protected]> wrote: >> >> Try this: >> >> Index: server/mpm/event/event.c >> =================================================================== >> --- server/mpm/event/event.c (revision 1203816) >> +++ server/mpm/event/event.c (working copy) >> @@ -1483,9 +1483,9 @@ >> rc = apr_pollset_poll(event_pollset, timeout_interval, &num, >> &out_pfd); >> if (rc != 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 >> called. >> (It seems to fix it for me from an ab standpoint, but I haven't looked >> in detail.) > > yep, that takes care of the breakage. Thanks, Jeff. > > but my fears about the performance of the design seem to be confirmed. my > fastest run so far with trunk + this patch, > > Requests per second: 7749.66 [#/sec] (mean)
backing up to the prior state (with the mutex), it would seem trivial to implement mutex macros that would maintain a rough contention % by using trylock first when built with some debug flag??? now what is bad contention? that depends on the extra CPU usage for dispatch and latency and xxx??? no idea what that would be; ~1-2%? > >> 2.4's Event, same ab invocation: >> >> Requests per second: 9410.79 [#/sec] (mean) >> >> worker from trunk: >> >> Requests per second: 10401.39 [#/sec] (mean) > > Greg > -- Born in Roswell... married an alien...
