I would agree. This "fix" is likely to be very expensive. Each thread is managing 100s to 1000s of connections, and with the current connection sharing model, many will be cross thread (a bad thing). With this "fix" each of those is going to knock the other thread off the poll loop which results in an expensive loop through the active connections.
On an unloaded system it is OK, to do this because the processors are otherwise unused, but on a loaded system it is going to cause the threads to spin. I would suggest using the TS-924 patch then backing this out. Alternatively we could modify the patch so that it was adaptive to load. TS=924 is a better way to address this. john On Fri, Sep 9, 2011 at 10:36 AM, Leif Hedstrom <zw...@apache.org> wrote: > On 09/09/2011 10:56 AM, Bryan Call wrote: > >> I ran some benchmarks on the 3.0.1 release and the 3.1.0 release with >> different options on and off. This benchmark was done with 1 client, 1 >> proxy, and 3 origin servers. The servers are 12 core (24 hyper-threaded) >> boxes and are the beefiest I could get a hold of. The response was only a 1 >> byte response, so that I wouldn't make the NIC a bottleneck. >> >> There are a couple things to note in the benchmark results: >> >> 1. There is a huge impact in performance in 3.0.1 and 3.1.0 having >> >> logging on and only proxying to the origin server. Turning off >> logging increases the performance by 185%. I think there can be >> some large performance gains to be won here. >> 2. There was a huge performance decrease from 3.0.1 to 3.1.0 with >> >> just turning off the cache and only proxying to the origin. 3.1.0 >> is only performing at 14% of what 3.0.1 is. Turning off shared >> sessions removes this decrease in performance, so some of the work >> that Leif is doing might resolve this. I am going to benchmark >> his patch today. >> >> > > I'm wondering if we should back out the two-line "fix" from TS-880, and > instead do the proposed fix from TS-924 ? > > Thoughts? > > -- leif > >
