You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Aaron Bannert <aa...@clove.org> on 2002/04/24 02:04:10 UTC
[PATCH] improve request multiplexing in AB
This patch corrects some problems in the ability of AB to handle
concurrent processing by:
- enabling nonblocking connect()s.
- preventing APR from performing blocking reads, allowing AB to
multiplex over its own set of descriptors.
Pre-patch: worker MPM with 2 children, 10 threads each: 10-20 req/sec
Post-patch: worker MPM with 2 children, 10 threads each: 750 req/sec
Post-patch: worker MPM with 2 children, 50 threads each: 735 req/sec
According to server-status I am now able to consistently occupy *all*
worker threads in the 10thr/child case, and almost all in the 50thr/child
case (my test hardware probably can't keep up). Actually, most of the
time they are all in the "closing connection" state.
** If you saw poor concurrent performance with the worker MPM while
testing with AB, please retest and submit your results.
-aaron
Index: support/ab.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/support/ab.c,v
retrieving revision 1.95
diff -u -r1.95 ab.c
--- support/ab.c 14 Apr 2002 09:21:43 -0000 1.95
+++ support/ab.c 23 Apr 2002 23:36:44 -0000
@@ -853,6 +853,10 @@
SOCK_STREAM, c->ctx)) != APR_SUCCESS) {
apr_err("socket", rv);
}
+ if ((rv = apr_setsocketopt(c->aprsock, APR_SO_NONBLOCK, 1))
+ != APR_SUCCESS) {
+ apr_err("socket nonblock", rv);
+ }
c->start = apr_time_now();
if ((rv = apr_connect(c->aprsock, destsa)) != APR_SUCCESS) {
if (APR_STATUS_IS_EINPROGRESS(rv)) {
@@ -941,16 +945,14 @@
char respcode[4]; /* 3 digits and null */
r = sizeof(buffer);
- apr_setsocketopt(c->aprsock, APR_SO_TIMEOUT, aprtimeout);
status = apr_recv(c->aprsock, buffer, &r);
- if (r == 0 || (status != APR_SUCCESS && !APR_STATUS_IS_EAGAIN(status))) {
+ if (APR_STATUS_IS_EAGAIN(status))
+ return;
+ if (r == 0 || status != APR_SUCCESS) {
good++;
close_connection(c);
return;
}
-
- if (APR_STATUS_IS_EAGAIN(status))
- return;
totalread += r;
if (c->read == 0) {
Re: [PATCH] improve request multiplexing in AB
Posted by Greg Ames <gr...@apache.org>.
Bill Stoddard wrote:
>
> Does this change effectively negate the -c option?
It should actually make -c more accurate for values > 1.
As I understand it, some of the socket calls (such as connect) in ab were
blocking. Since ab is not multi-threaded or multi-process, that single threads
all connections periodically.
Thanks, Aaron!
Greg
Re: [PATCH] improve request multiplexing in AB
Posted by Jeff Trawick <tr...@attglobal.net>.
"Bill Stoddard" <bi...@wstoddard.com> writes:
> Does this change effectively negate the -c option?
Maybe I didn't read the patch properly, but my understanding was that
the changes only affect how a given connection is handled and do not
affect how many connections ab tries to handle concurrently.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: [PATCH] improve request multiplexing in AB
Posted by Bill Stoddard <bi...@wstoddard.com>.
Does this change effectively negate the -c option?
Bill
----- Original Message -----
From: "Aaron Bannert" <aa...@clove.org>
To: <de...@httpd.apache.org>
Sent: Tuesday, April 23, 2002 8:04 PM
Subject: [PATCH] improve request multiplexing in AB
> This patch corrects some problems in the ability of AB to handle
> concurrent processing by:
>
> - enabling nonblocking connect()s.
> - preventing APR from performing blocking reads, allowing AB to
> multiplex over its own set of descriptors.
>
> Pre-patch: worker MPM with 2 children, 10 threads each: 10-20 req/sec
> Post-patch: worker MPM with 2 children, 10 threads each: 750 req/sec
> Post-patch: worker MPM with 2 children, 50 threads each: 735 req/sec
>
> According to server-status I am now able to consistently occupy *all*
> worker threads in the 10thr/child case, and almost all in the 50thr/child
> case (my test hardware probably can't keep up). Actually, most of the
> time they are all in the "closing connection" state.
>
> ** If you saw poor concurrent performance with the worker MPM while
> testing with AB, please retest and submit your results.
>
> -aaron
>
>
> Index: support/ab.c
> ===================================================================
> RCS file: /home/cvspublic/httpd-2.0/support/ab.c,v
> retrieving revision 1.95
> diff -u -r1.95 ab.c
> --- support/ab.c 14 Apr 2002 09:21:43 -0000 1.95
> +++ support/ab.c 23 Apr 2002 23:36:44 -0000
> @@ -853,6 +853,10 @@
> SOCK_STREAM, c->ctx)) != APR_SUCCESS) {
> apr_err("socket", rv);
> }
> + if ((rv = apr_setsocketopt(c->aprsock, APR_SO_NONBLOCK, 1))
> + != APR_SUCCESS) {
> + apr_err("socket nonblock", rv);
> + }
> c->start = apr_time_now();
> if ((rv = apr_connect(c->aprsock, destsa)) != APR_SUCCESS) {
> if (APR_STATUS_IS_EINPROGRESS(rv)) {
> @@ -941,16 +945,14 @@
> char respcode[4]; /* 3 digits and null */
>
> r = sizeof(buffer);
> - apr_setsocketopt(c->aprsock, APR_SO_TIMEOUT, aprtimeout);
> status = apr_recv(c->aprsock, buffer, &r);
> - if (r == 0 || (status != APR_SUCCESS && !APR_STATUS_IS_EAGAIN(status))) {
> + if (APR_STATUS_IS_EAGAIN(status))
> + return;
> + if (r == 0 || status != APR_SUCCESS) {
> good++;
> close_connection(c);
> return;
> }
> -
> - if (APR_STATUS_IS_EAGAIN(status))
> - return;
>
> totalread += r;
> if (c->read == 0) {
>
Re: [PATCH] improve request multiplexing in AB
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Apr 23, 2002 at 05:04:10PM -0700, Aaron Bannert wrote:
> This patch corrects some problems in the ability of AB to handle
> concurrent processing by:
Oh, and the reason I posted this instead of just committing was because
AB is a nasty beast and I wanted to make sure I didn't break anything. :)
-aaron
Re: [PATCH] improve request multiplexing in AB
Posted by Jeff Trawick <tr...@attglobal.net>.
Aaron Bannert <aa...@clove.org> writes:
> This patch corrects some problems in the ability of AB to handle
> concurrent processing by:
>
> - enabling nonblocking connect()s.
> - preventing APR from performing blocking reads, allowing AB to
> multiplex over its own set of descriptors.
+1
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: [PATCH] improve request multiplexing in AB
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1
At 5:04 PM -0700 4/23/02, Aaron Bannert wrote:
>This patch corrects some problems in the ability of AB to handle
>concurrent processing by:
>
> - enabling nonblocking connect()s.
> - preventing APR from performing blocking reads, allowing AB to
> multiplex over its own set of descriptors.
>
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither" - T.Jefferson
Re: [PATCH] improve request multiplexing in AB
Posted by Brian Pane <bp...@pacbell.net>.
Cliff Woolley wrote:
>On Tue, 23 Apr 2002, Aaron Bannert wrote:
>
>>This patch corrects some problems in the ability of AB to handle
>>concurrent processing by:
>> - enabling nonblocking connect()s.
>> - preventing APR from performing blocking reads, allowing AB to
>> multiplex over its own set of descriptors.
>>** If you saw poor concurrent performance with the worker MPM while
>>testing with AB, please retest and submit your results.
>>
>
>May I just say HELL YEAH! :) That's awesome. Attached are some runs I
>just did before and after applying your patch to ab (nothing else
>changed... I didn't even stop and restart httpd between runs). Included
>are a few dumps from mod_status during each ab run.\
>
Works great with leader/follower, too (although so did the
unpatched ab)...+1.
--Brian
Re: [PATCH] improve request multiplexing in AB
Posted by Cliff Woolley <jw...@virginia.edu>.
On Tue, 23 Apr 2002, Aaron Bannert wrote:
> This patch corrects some problems in the ability of AB to handle
> concurrent processing by:
> - enabling nonblocking connect()s.
> - preventing APR from performing blocking reads, allowing AB to
> multiplex over its own set of descriptors.
> ** If you saw poor concurrent performance with the worker MPM while
> testing with AB, please retest and submit your results.
May I just say HELL YEAH! :) That's awesome. Attached are some runs I
just did before and after applying your patch to ab (nothing else
changed... I didn't even stop and restart httpd between runs). Included
are a few dumps from mod_status during each ab run.
Summary for a concurrency level of 100, default worker params:
Without patch With patch
RPS 60.69 1372.75
KBPS 103.72 2345.90
In other words:
++1 on the patch =-)
--Cliff