On Tue, Nov 15, 2011 at 10:51 AM, <[email protected]> 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 > num--; > } /* while for processing poll */ > > + { > + /* TODO: break out to separate function */ > + int i; > + > + for (i = 0; i < threads_per_child; i++) { > + ap_equeue_t *eq = 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. so I tried some simple benchmarks. If I measure the throughput of a single keepalive connection,
$ bin/ab -k -c 1 -n 1000 localhost/index.html ... Requests per second: 10.18 [#/sec] (mean) it looks broken. 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. 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 p.s. this is on my ThinkPad W520 with 32 bit Linux Ubuntu natty
