Bill Stoddard <[EMAIL PROTECTED]> writes: > Joe Schaefer wrote:
[...] > > ie 1 server w/ 5 threads. The closer_thread's queue/pollset size > > are capped at 100 with this config. > > Running ab -n 10000 -c $concurrency http://localhost/ > > concurency requests/sec > > unpatched with patch (CLOSER_DEBUG undefined) > > 5 2995 2923 > > 10 2999 2990 > > 20 2991 2935 > > 50 2975 2896 > > 100 2715 2853 > > 200 2530 2659 > > 500 1871 2353 > > 600 1014 2316 > > 700 547 2094 > > 800 450 2021 > > 900 428 2042 > > 1000 230 2000 > > > > I'd like to see if others can replicate these results. This is sort > of the behaviour I expected; patched server slower at low concurrency > rates because the server is doing more queuing work for little > benefit. I also expected the cross over in performance as the > concurrency increased, but I am -really- suprised at the magnitude of > the difference beginning around 500 concurrent clients!! I almost > wonder if a large number of requests are actually failing in > the patched case under high load... Is there any interest in this patch? Eventually it might even be nice to extend the concept to keepalives, but I suppose that would mean introducing some state management into ap_process_connection. -- Joe Schaefer
