You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2004/08/25 22:03:08 UTC
[PATCH] lingering close thread for worker
The concept of multiplexing apache's lingering
close comes from lingerd, but I thought it'd be
interesting to try the same thing for worker with
a dedicated closer thread. This is my first foray
into thread programming so expect rookie mistakes
in the patch (please be gentle :-).
The patch is in three parts, one for httpd-2.0 head
one for apr head, and two new files closer.[ch] that
need to be placed in httpd-2.0/server/mpm/worker.
The files implementing the closer thread are
available here
http://cvs.apache.org/~joes/closer.h
http://cvs.apache.org/~joes/closer.c
Patches for httpd-2.0 and apr HEAD are attached:
Re: [PING] Re: [PATCH] lingering close thread for worker
Posted by Paul Querna <ch...@force-elite.com>.
On Wed, 2004-09-22 at 15:00 -0400, Bill Stoddard wrote:
> > 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.
>
Yes, I am interested too. I have taken Greg's patch and turned it into
a Full 'event' MPM. I am currently re-working some of apr_pollset_* so
I can avoid all locking when adding or removing FDs to a pollset. Once I
have the patch to APR done, I planned on submitting the event MPM to be
included in CVS.
-Paul Querna
Re: [PING] Re: [PATCH] lingering close thread for worker
Posted by Bill Stoddard <bi...@wstoddard.com>.
Joe Schaefer wrote:
> Bill Stoddard <bi...@wstoddard.com> 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
[PING] Re: [PATCH] lingering close thread for worker
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Bill Stoddard <bi...@wstoddard.com> 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
Re: [PATCH] lingering close thread for worker
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Bill Stoddard <bi...@wstoddard.com> writes:
[...]
> I almost wonder if a large number of requests are actually failing in
> the patched case under high load...
Me too, but there are no failed requests reported by ab:
/usr/local/apache2/bin/ab -n 10000 -c 1000 http://localhost/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Finished 10000 requests
Server Software: Apache/2.1.0-dev
Server Hostname: localhost
Server Port: 80
Document Path: /
Document Length: 1456 bytes
Concurrency Level: 1000
Time taken for tests: 5.258547 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 19212606 bytes
HTML transferred: 14584752 bytes
Requests per second: 1901.67 [#/sec] (mean)
Time per request: 525.855 [ms] (mean)
Time per request: 0.526 [ms] (mean, across all concurrent requests)
Transfer rate: 3567.91 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 87 490.4 5 3021
Processing: 10 79 122.8 63 1540
Waiting: 5 72 122.8 56 1533
Total: 35 167 577.7 67 4550
Percentage of the requests served within a certain time (ms)
50% 67
66% 75
75% 80
80% 81
90% 83
95% 104
98% 3093
99% 3708
100% 4550 (longest request)
--
Joe Schaefer
Re: [PATCH] lingering close thread for worker
Posted by Bill Stoddard <bi...@wstoddard.com>.
Joe Schaefer wrote:
> Joe Schaefer <jo...@sunstarsys.com> writes:
>
>
>>The concept of multiplexing apache's lingering
>>close comes from lingerd, but I thought it'd be
>>interesting to try the same thing for worker with
>>a dedicated closer thread.
>
>
> The patch is intended to improve worker's scaling
> characteristics without adversely affecting per-request
> latency. I don't have a good testbed for checking this
> out, but I've run a few microbenchmarks with ab (on
> the same host the server is running on) to see what
> happens when the server is overdriven by lots of
> concurrent requests.
>
> Setup: standard installation w/ worker's config
> reduced to
>
> <IfModule worker.c>
> StartServers 1
> MaxClients 5
> MinSpareThreads 1
> MaxSpareThreads 5
> ThreadsPerChild 5
> MaxRequestsPerChild 0
> </IfModule>
>
> 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...
Bill
Re: [PATCH] lingering close thread for worker
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Joe Schaefer <jo...@sunstarsys.com> writes:
> The concept of multiplexing apache's lingering
> close comes from lingerd, but I thought it'd be
> interesting to try the same thing for worker with
> a dedicated closer thread.
The patch is intended to improve worker's scaling
characteristics without adversely affecting per-request
latency. I don't have a good testbed for checking this
out, but I've run a few microbenchmarks with ab (on
the same host the server is running on) to see what
happens when the server is overdriven by lots of
concurrent requests.
Setup: standard installation w/ worker's config
reduced to
<IfModule worker.c>
StartServers 1
MaxClients 5
MinSpareThreads 1
MaxSpareThreads 5
ThreadsPerChild 5
MaxRequestsPerChild 0
</IfModule>
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
--
Joe Schaefer