You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Cliff Woolley <jw...@virginia.edu> on 2002/03/31 19:45:00 UTC
[PATCH] another bucket allocator implementation
Here's a heavier-weight but pool-free and potentially faster alternative
to Brian's proposal for your benchmarking enjoyment.... :)
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: [PATCH] another bucket allocator implementation
Posted by Brian Pane <bp...@pacbell.net>.
> requests/second
> ---------------
> Test 2.0.34 2.0.34 + 2.0.34 +
> file baseline Brian's patch Cliff's patch
> 50k.shtml 654 667 686
> incl.shtml 1870 1992 2007
>
> (I put copies of these shtml files in
> http://icarus.apache.org/~brianp/ )
By the way, the scores for an equivalently configured
1.3.24 on these same tests:
50k.shtml 196
incl.shtml 1494
--Brian
Re: [PATCH] another bucket allocator implementation
Posted by Cliff Woolley <jw...@virginia.edu>.
On Mon, 1 Apr 2002, Dale Ghent wrote:
> I just ran the current HEAD code against your files and a stock httpd.conf
> (with SSI enabled) against your files. I did this on a dual 300Mhz Ultra2
> running Solaris 8 with the -11 kernel patch.
Can you do me a favor and run 2.0.34 in the same configuration as a
baseline?
Thanks!
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: [PATCH] another bucket allocator implementation
Posted by Dale Ghent <da...@elemental.org>.
On Sun, 31 Mar 2002, Brian Pane wrote:
| requests/second
| ---------------
| Test 2.0.34 2.0.34 + 2.0.34 +
| file baseline Brian's patch Cliff's patch
| 50k.shtml 654 667 686
| incl.shtml 1870 1992 2007
|
| (I put copies of these shtml files in
| http://icarus.apache.org/~brianp/ )
|
| We need to do some multiprocessor testing on Solaris etc,
| of course, but my initial conclusion is that we should use
| Cliff's patch.
I just ran the current HEAD code against your files and a stock httpd.conf
(with SSI enabled) against your files. I did this on a dual 300Mhz Ultra2
running Solaris 8 with the -11 kernel patch.
ab -c 1 -v 1 -n 1000
50k.shtml:
Requests per second: 128.05 [#/sec] (mean)
Time per request: 0.008 [ms] (mean)
Time per request: 0.008 [ms] (mean, across all concurrent requests)
Transfer rate: 6280.05 [Kbytes/sec] received
incl.shtml:
Requests per second: 336.18 [#/sec] (mean)
Time per request: 0.003 [ms] (mean)
Time per request: 0.003 [ms] (mean, across all concurrent requests)
Transfer rate: 147.58 [Kbytes/sec] received
/dale
Re: [PATCH] another bucket allocator implementation
Posted by Cliff Woolley <jw...@virginia.edu>.
On Sun, 31 Mar 2002, Brian Pane wrote:
> requests/second
> ---------------
> Test 2.0.34 2.0.34 + 2.0.34 +
> file baseline Brian's patch Cliff's patch
> 50k.shtml 654 667 686
> incl.shtml 1870 1992 2007
Sweet!! In both cases this is really great news.
PS: I remembered at lunch that there was a buglet in
apr_bucket_alloc_destroy() I'd forgotten to fix. Since list itself is
allocated from list->allocator, we need to save a pointer to the allocator
before we call apr_allocator_free() so that we will still have a valid
pointer to pass to apr_allocator_destroy() afterward. Attached is a
revised patch.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: [PATCH] another bucket allocator implementation
Posted by Brian Pane <bp...@pacbell.net>.
Cliff Woolley wrote:
>Here's a heavier-weight but pool-free and potentially faster alternative
>to Brian's proposal for your benchmarking enjoyment.... :)
>
Here are some the results of some initial testing.
All tests were run on uniprocessor Linux x86, with
"ab -c1 -n1000" on the same machine as the httpd.
requests/second
---------------
Test 2.0.34 2.0.34 + 2.0.34 +
file baseline Brian's patch Cliff's patch
50k.shtml 654 667 686
incl.shtml 1870 1992 2007
(I put copies of these shtml files in
http://icarus.apache.org/~brianp/ )
We need to do some multiprocessor testing on Solaris etc,
of course, but my initial conclusion is that we should use
Cliff's patch.
--Brian