httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: ap_r patch performance comparison
Date Fri, 19 Jan 2001 05:59:07 GMT
On Thu, Jan 18, 2001 at 09:32:00PM -0800, wrote:
> The tests themselves were run on my computer.  I started the server, and ran
> ab on the same machine.  After each test, I stopped the server, and moved the
> error log out of the way (That's another topic).  The ab command was always
> the same:
> 	./ab -n 10000 -c 200 http://localhost:8080/

The tests that I ran had no -c switch. I just did a quick test with -c 10
and -c 100 on my box and the numbers were about the same. Not sure how you
got the 2.0 numbers higher than 1.3 (my test always had 1.3 with higher
req/sec, but lower thruput).

> And, the results:   (strace's to be generated ASAP)
> 	Run		1			2
> Server
> 1.3			115.96 req/sec		115.96 req/sec
> 			768.49 kb/sec		771.45 bb/sec
> 2.0 (unpatched)		35 req/sec		Not Done
> 			164.87 kb/sec
> 2.0 (greg)		90.16 req/sec		227.69 req/sec
> 			424.72 kb/sec		1083.38 kb/sec
> 2.0 (rbb)		89.71 req/sec
> 			420.65 kb/sec
> 2.0 (rbb2*)		93.00 req/sec		234.09 req/sec
> 			436.06 kb/sec		1106.45 kb/sec

That's great that 2.0 appears to be faster than 1.3, but I'm suspect of the
numbers given my own *very* brief testing. Regardless, it would seem that we
aren't too far off.

> *  The differences between rbb and rbb2 are relatively simple.  I wanted to 
> compare apples to apples, so I modified my patch to use AP_MIN_TO_WRITE as 
> size of the bucket buffer, and I used malloc with heap buckets instead of 
> palloc with pool buckets.

That's Goodness(tm).

> The difference between Greg's patch and mine is minimal when it comes to
> the actual performance.

Sure seems that way. The numbers are within a few percent; yours would
appear slight faster. But I'd consider that negligible because the patches
were built to demonstrate an algorithm/process, and with no attention paid
to incremental performance (at least that's the case with mine). Both could
have further tweaking of performance.

> I want to examine the straces a bit, results will be posted,

They should look exactly the same.

> but it really looks like this is going to come down to a matter
> of personally preference.  Do we want a solution that works for all bucket
> programs, or do we want one that allows programmers to use both ap_r and
> direct bucket code.

That is effectively the crux of the difference between the patches. Although
I might characterize it as my patch being more robust against subtle errors
introducing ordering problems (caused by mixing APIs, or forgetting to
standardize() the brigade).


Greg Stein,

View raw message