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.
FWIW, I am definitely interested (especially if we can get confirmation of the results on several different platforms from several different folks). greg ames and i have a patch that essentially does this for keep-alives, it's been posted to the dev@ list in the recent past. No time to work on it myself tho, sorry.
Bill
