You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Stas Bekman <st...@stason.org> on 2002/01/26 06:21:11 UTC
Apache::args vs Apache::Request speed
Joe Schaefer wrote:
>>mod_perl specific examples from the guide/book ($r->args vs
>>Apache::Request::param, etc)
>>
>
> Well, I've complained about that one before, and since the
> guide's text hasn't changed yet I'll try saying it again:
>
> Apache::Request::param() is FASTER THAN Apache::args(),
> and unless someone wants to rewrite args() IN C, it is
> likely to remain that way. PERIOD.
>
> Of course, if you are satisfied using Apache::args, than it would
> be silly to change "styles".
Well, I've run the benchmark and it wasn't the case. Did it change
recently? Or do you think that the benchmark is not fair?
we are talking about this item
http://perl.apache.org/guide/performance.html#Apache_args_vs_Apache_Request
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Apache::args vs Apache::Request speed
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>Also I was only a user of Apache::Request, so I know very little about
>>it. It's about a time I should learn its guts. Does this library work
>>for 2.0 as is, or is there a new implementation for 2.0? I see that ToDo
>>says that it should be ported to 2.0.
>>
>
> I've never tried using it with 2.0, but I'd guess that it won't run
> there as-is. But that should be our top priority after we release
> 1.0. It's really important that we get out a release version that
> we promise not to tinker around with API-wise, so people can start
> developing derivative products without too much worry that we'll break
> their code. Lots of people use apreq outside of the Perl community,
> and getting a 1.x release out there for the C API is very important
> to them.
Certainly.
>>So first the C lib should be ported and then the Perl glue should be
>>written, right?
>>
>
> Yes, exactly. Choosing a new C API for apreq that's geared toward
> apache 2.0 AND improves upon some of the deficiencies of the current
> libapreq is an important first step, and IMO needs to be debated and
> created on the apreq-dev list NOW. It would be great if you signed up
> to that list so we can start discussing these issues there. I've cc-d
> this email to the list just in case :)
I'm on the list now. Let's start.
--
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Apache::args vs Apache::Request speed
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Also I was only a user of Apache::Request, so I know very little about
> it. It's about a time I should learn its guts. Does this library work
> for 2.0 as is, or is there a new implementation for 2.0? I see that ToDo
> says that it should be ported to 2.0.
I've never tried using it with 2.0, but I'd guess that it won't run
there as-is. But that should be our top priority after we release
1.0. It's really important that we get out a release version that
we promise not to tinker around with API-wise, so people can start
developing derivative products without too much worry that we'll break
their code. Lots of people use apreq outside of the Perl community,
and getting a 1.x release out there for the C API is very important
to them.
> So first the C lib should be ported and then the Perl glue should be
> written, right?
Yes, exactly. Choosing a new C API for apreq that's geared toward
apache 2.0 AND improves upon some of the deficiencies of the current
libapreq is an important first step, and IMO needs to be debated and
created on the apreq-dev list NOW. It would be great if you signed up
to that list so we can start discussing these issues there. I've cc-d
this email to the list just in case :)
Best.
--
Joe Schaefer
Re: Apache::args vs Apache::Request speed
Posted by Joe Schaefer <jo...@sunstarsys.com>.
John Siracusa <si...@mindspring.com> writes:
> I'm cc-ing this to the Mac OS X Perl list in the hopes that someone can
> provide a test environment for you. (I would, but my OS X box is behind a
> firewall at work.)
>
> So how about it, macosx@perl.org folks, can any of you help get libapreq up
> and running on OS X an long last? (See message quoted below)
>
Maybe this will help:
http://fink.sourceforge.net/doc/porting/porting.html
The Unix build of libapreq goes in 3 steps:
1) build a static c library: libapreq.a
2) build object files Request.o, Cookie.o
3) link each object file against libapreq.a to
make shared libraries Request.so Cookie.so
So each file gets it's own copy of libapreq, symbols and
all. For ELF-based systems, that's not a problem since
the linking executable knows not only the library's filename,
but also the location of the desired symbol within the file
(actually there's something called a jump table inside the
.so that provides some necessary indirection, but that's a
technicality that's not particularly relevant to the issue.)
AIUI, the problem with OS/X is that their linker doesn't
provide the executable with a similar addressing scheme
for unresolved symbols; it just tells the executable which
libraries are needed to resolve them without also telling
it "where to look" for a given symbol. So because Request.bundle
and Cookie.bundle both (accidentally?) provide resolution for
libapreq's symbols, the executable gets confused and bails out.
If I'm right here, then removing the libapreq symbols from
Cookie.bundle and Request.bundle should do the trick. There
are lots of ways to reorganize things in order to achieve this,
and I'm somewhat surprised that none of the OS/X folks have
made any progress in this regard.
So maybe I'm wrong, but I don't think any of us will learn the
answer until some OS/X person actually _attempts_ to fix it.
--
Joe Schaefer
Re: Apache::args vs Apache::Request speed
Posted by Andrew Ho <an...@tellme.com>.
Heyas,
JS>Would someone PLEASE volunteer to try to compile and test
JS>apache+mod_perl & libapreq on OS/X using the experimental
JS>code I posted there? Even if you can't get it working,
JS>ANY feedback about what happened when you tried would be
JS>VERY helpful.
Slightly off topic; I'd like to help with this but I have this curious
problem. I'm trying to build Perl 5.6.itself 1 on Mac OS X (with the
latest 10.1.2 update freshly installed, using the compiler from the
developer tools CD that comes with OS X when you buy the 10.1 boxed
version) before building Apache/mod_perl.
So I go through the entire Configure sequence, and then no Makefile gets
created (it goes through the entire routine of saying it's generating a
Makefile, but whether I run Makefile.SH or have it done through Configure,
no Makefile actually ever gets created).
Has anybody else seen this really weird behavior trying to build Perl
5.6.1 on Mac OS X? A web search didn't turn up any relevant posts.
Humbly,
Andrew
----------------------------------------------------------------------
Andrew Ho http://www.tellme.com/ andrew@tellme.com
Engineer info@tellme.com Voice 650-930-9062
Tellme Networks, Inc. 1-800-555-TELL Fax 650-930-9101
----------------------------------------------------------------------
Re: Apache::args vs Apache::Request speed
Posted by Matt Sergeant <ma...@sergeant.org>.
On 1 Feb 2002, Joe Schaefer wrote:
> Would someone PLEASE volunteer to try to compile and test
> apache+mod_perl & libapreq on OS/X using the experimental
> code I posted there? Even if you can't get it working,
> ANY feedback about what happened when you tried would be
> VERY helpful.
OK, if someone can communicate with me in private, seriously dumbed down
details, I can try this. I'm a libapreq committer, and have sourceforge
farm access, so I'll do my best there - though last time I tried I
couldn't get onto their OSX box...
--
<!-- Matt -->
<:->Get a smart net</:->
Re: Apache::args vs Apache::Request speed
Posted by John Siracusa <si...@mindspring.com>.
On 2/1/02 3:39 PM, Ian Ragsdale wrote:
> On the other hand, I'd be happy to compile it, but what would I need to do
> to test it?
I'm in the process of trying this too (just building a mod_perl httpd in OS
X is a bit tricky...) To test it, I think all you need to do is put these
two lines in your "startup.pl" file (or whatever):
use Apache::Request;
use Apache::Cookie;
If that works, the next step is to make an actual apache handler that uses
both the modules to actually do something. And if that works, post detailed
instructions (starting with the wget of the source tarballs :)
-John
Re: Apache::args vs Apache::Request speed
Posted by Ian Ragsdale <ia...@SKYLIST.net>.
On 2/1/02 2:21 PM, "Joe Schaefer" <jo...@sunstarsys.com> wrote:
> Ian Ragsdale <ia...@SKYLIST.net> writes:
>
>> How about setting something up on SourceForge? I know they have OS X
>> environments available for compiling and testing.
>
> apreq is an ASF project; IMO what we need now is a hero, not a
> change of venue.
>
I'm not suggesting you switch it to stay at sourceforge, I'm just saying
that they have OS X boxes you can compile & test on. Seems pretty simple to
me. I'd volunteer my own computer, but it's an iBook and is constantly
switching IP addresses due to moving around.
On the other hand, I'd be happy to compile it, but what would I need to do
to test it?
Ian
[OT] Mac OS X compilation woes (Was: Apache::args vs Apache::Request
speed)
Posted by Andrew Ho <an...@tellme.com>.
Hello,
JS>An initial build and install of:
JS> http://www.apache.org/~joes/libapreq-1.0-rc1.tar.gz
JS>
JS>on a previously-working apache 1.3.22 mod_perl 1.26 server on OS X 10.1.2
JS>with this:
JS> use Apache::Request;
JS> use Apache::Cookie;
JS>
JS>In its startup.pl file causes the following:
JS>
JS># bin/httpd -d /usr/local/apache -f conf/httpd.conf
JS>dyld: bin/httpd Undefined symbols:
JS>_ap_day_snames
JS>...
JS>_sv2request_rec
I'm having a similar problem but it's for ANY symbols in a .a that you
compile something with. e.g. say I have a C library and it lives in
/usr/local/lib/libfoo.a (include in /usr/local/include/foo.h) and exports
void foo(). If I have a test C program tester.c:
#include <foo.h>
int main { foo(); return 0 }
And I compile it so:
% cc -o tester -lfoo tester.c
And I run it, I'll get the undefined symbols error that you paste above.
This happens for me with a variety of existing open source libraries that
I've built. I theorize your problem with libapreq may stem from a similar
problem (I'm also running 10.1.2).
Humbly,
Andrew
----------------------------------------------------------------------
Andrew Ho http://www.tellme.com/ andrew@tellme.com
Engineer info@tellme.com Voice 650-930-9062
Tellme Networks, Inc. 1-800-555-TELL Fax 650-930-9101
----------------------------------------------------------------------
Re: Apache::args vs Apache::Request speed
Posted by John Siracusa <si...@mindspring.com>.
On 2/1/02 3:21 PM, Joe Schaefer wrote:
> Would someone PLEASE volunteer to try to compile and test
> apache+mod_perl & libapreq on OS/X using the experimental
> code I posted there? Even if you can't get it working,
> ANY feedback about what happened when you tried would be
> VERY helpful.
(The below may not be very helpful, but I've gotta run right now. I'll try
more this weekend if I can.)
An initial build and install of:
http://www.apache.org/~joes/libapreq-1.0-rc1.tar.gz
on a previously-working apache 1.3.22 mod_perl 1.26 server on OS X 10.1.2
with this:
use Apache::Request;
use Apache::Cookie;
In its startup.pl file causes the following:
# bin/httpd -d /usr/local/apache -f conf/httpd.conf
dyld: bin/httpd Undefined symbols:
_ap_day_snames
_ap_find_path_info
_ap_get_client_block
_ap_getword
_ap_getword_conf
_ap_hard_timeout
_ap_ind
_ap_kill_timeout
_ap_log_rerror
_ap_make_array
_ap_make_dirstr_parent
_ap_make_table
_ap_month_snames
_ap_null_cleanup
_ap_pcalloc
_ap_pfclose
_ap_pfdopen
_ap_popenf
_ap_psprintf
_ap_pstrcat
_ap_pstrdup
_ap_pstrndup
_ap_push_array
_ap_register_cleanup
_ap_setup_client_block
_ap_should_client_block
_ap_table_add
_ap_table_do
_ap_table_get
_ap_table_set
_ap_table_unset
_ap_unescape_url
_hvrv2table
_mod_perl_tie_table
_perl_request_rec
_sv2request_rec
More later, I hope... :)
-John
Re: Apache::args vs Apache::Request speed
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Ian Ragsdale <ia...@SKYLIST.net> writes:
> How about setting something up on SourceForge? I know they have OS X
> environments available for compiling and testing.
apreq is an ASF project; IMO what we need now is a hero, not a
change of venue.
[...]
> > On 1/28/02 2:02 PM, Joe Schaefer <jo...@sunstarsys.com> wrote:
[...]
> >> I hope a new release will be just around the corner, but if you want
> >> to test out some of the latest stuff, have a look at
> >>
> >> http://www.apache.org/~joes/
Would someone PLEASE volunteer to try to compile and test
apache+mod_perl & libapreq on OS/X using the experimental
code I posted there? Even if you can't get it working,
ANY feedback about what happened when you tried would be
VERY helpful.
Thanks alot.
--
Joe Schaefer
Re: Apache::args vs Apache::Request speed
Posted by Ian Ragsdale <ia...@SKYLIST.net>.
How about setting something up on SourceForge? I know they have OS X
environments available for compiling and testing.
Ian
On 1/28/02 2:19 PM, "John Siracusa" <si...@mindspring.com> wrote:
> I'm cc-ing this to the Mac OS X Perl list in the hopes that someone can
> provide a test environment for you. (I would, but my OS X box is behind a
> firewall at work.)
>
> So how about it, macosx@perl.org folks, can any of you help get libapreq up
> and running on OS X an long last? (See message quoted below)
>
> -John
>
> On 1/28/02 2:02 PM, Joe Schaefer <jo...@sunstarsys.com> wrote:
>> Stas Bekman <st...@stason.org> writes:
>>> Great! Now we have an even broader benchmark. Please tell me when 1.0 is
>>> released (in case I get carried away with other things and don't notice
>>> the announce) and I'll make sure to update my benchmarking package,
>>> re-run the benchmarks and correct the results in the guide.
>>
>> Great- there's a typo or two in the handler_do sub, but they should be
>> pretty obvious when you try to run it.
>>
>> I hope a new release will be just around the corner, but if you want
>> to test out some of the latest stuff, have a look at
>>
>> http://www.apache.org/~joes/
>>
>> I don't think we'll have a 1.0 that works on OS/X, but I might be able
>> to include a patch in the distro that will build the C api of libapreq
>> directly into httpd. This might allow OS/X to run Apache::Request and
>> Apache::Cookie at the same time, but that platform is unavailable to me
>> for testing.
>
>
Re: Apache::args vs Apache::Request speed
Posted by John Siracusa <si...@mindspring.com>.
I'm cc-ing this to the Mac OS X Perl list in the hopes that someone can
provide a test environment for you. (I would, but my OS X box is behind a
firewall at work.)
So how about it, macosx@perl.org folks, can any of you help get libapreq up
and running on OS X an long last? (See message quoted below)
-John
On 1/28/02 2:02 PM, Joe Schaefer <jo...@sunstarsys.com> wrote:
> Stas Bekman <st...@stason.org> writes:
>> Great! Now we have an even broader benchmark. Please tell me when 1.0 is
>> released (in case I get carried away with other things and don't notice
>> the announce) and I'll make sure to update my benchmarking package,
>> re-run the benchmarks and correct the results in the guide.
>
> Great- there's a typo or two in the handler_do sub, but they should be
> pretty obvious when you try to run it.
>
> I hope a new release will be just around the corner, but if you want
> to test out some of the latest stuff, have a look at
>
> http://www.apache.org/~joes/
>
> I don't think we'll have a 1.0 that works on OS/X, but I might be able
> to include a patch in the distro that will build the C api of libapreq
> directly into httpd. This might allow OS/X to run Apache::Request and
> Apache::Cookie at the same time, but that platform is unavailable to me
> for testing.
Re: Apache::args vs Apache::Request speed
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Great! Now we have an even broader benchmark. Please tell me when 1.0 is
> released (in case I get carried away with other things and don't notice
> the announce) and I'll make sure to update my benchmarking package,
> re-run the benchmarks and correct the results in the guide.
Great- there's a typo or two in the handler_do sub, but they should be
pretty obvious when you try to run it.
I hope a new release will be just around the corner, but if you want
to test out some of the latest stuff, have a look at
http://www.apache.org/~joes/
I don't think we'll have a 1.0 that works on OS/X, but I might be able
to include a patch in the distro that will build the C api of libapreq
directly into httpd. This might allow OS/X to run Apache::Request and
Apache::Cookie at the same time, but that platform is unavailable to me
for testing.
--
Joe Schaefer
Re: Apache::args vs Apache::Request speed
Posted by Stas Bekman <st...@stason.org>.
mark warren bracher wrote:
> I didn't ever actually see a post with newer numbers, so here goes......
>
> I tested the same 50 clients/5000 requests as stas' test in the guide.
> one pass with 2 uri params; another with 26. naturally I ran it all on
> a server big (and quiescent) enough to handle the 50 concurrent
> requests. I left out CGI since we already know it is slow.
>
> /test/params and /test/args are mod_perl handlers (I don't use
> Apache::Registry for anything) ParamsTest and ArgsTest respectively. the
> code for both handlers and the relevant pieces of ab output are pasted
> in below.
>
> -------------------------------------------------------------
> name query_length | avtime completed failed rps
> -------------------------------------------------------------
> apache_args 25 | 33.77 5000 0 1481
> apache_request 25 | 33.17 5000 0 1507
> apache_args 337 | 43.51 5000 0 1141
> apache_request 337 | 45.31 5000 0 1103
> --------------------------------------------------------------
> Non-varying sub-test parameters:
> --------------------------------------------------------------
> concurrency : 50
> connections : 5000
>
> so $apr->param is marginally faster than $r->args for the shorter query,
> marginally slower for the longer one. I think this may be because we
> can return the full hash $r->args whereas we need to map over
> $apr->param to get a hash (so param gets called three times for the
> short query, 27 times for the larger one). still, much closer numbers
> than the former test...
Thanks Mark for pushing me to rerun the benchmark :)
Actually from the tests that I just run Apache::Request::param is
actually kicks $r->args on long inputs, and a bit faster on the short
query strings. Even though as you have noticed we call $q->param() 2 x
keys times more for each request.
Here are the results:
concurrency connections name query_length | avtime
completed failed rps
--------------------------------------------------------------------------------------------
50 5000 apache_request_param 25 | 53
5000 0 900
50 2000 apache_request_param 25 | 54
2000 0 884
50 5000 r_args 25 | 55
5000 0 879
50 2000 apache_request_param 105 | 54
2000 0 879
10 5000 apache_request_param 25 | 10
5000 0 878
50 5000 r_args 105 | 55
5000 0 876
10 2000 r_args 105 | 10
2000 0 869
50 5000 apache_request_param 105 | 56
5000 0 865
10 5000 apache_request_param 105 | 10
5000 0 855
10 5000 r_args 25 | 11
5000 0 850
10 2000 apache_request_param 105 | 11
2000 0 836
10 2000 r_args 25 | 11
2000 0 835
10 2000 apache_request_param 25 | 11
2000 0 832
50 2000 r_args 25 | 58
2000 0 827
10 5000 r_args 105 | 11
5000 0 810
50 5000 apache_request_param 207 | 64
5000 0 754
50 2000 apache_request_param 337 | 64
2000 0 750
10 2000 apache_request_param 207 | 12
2000 0 749
10 2000 apache_request_param 337 | 12
2000 0 749
50 2000 apache_request_param 207 | 64
2000 0 749
10 5000 apache_request_param 207 | 12
5000 0 746
50 2000 r_args 105 | 64
2000 0 744
10 5000 apache_request_param 337 | 12
5000 0 732
50 5000 r_args 207 | 72
5000 0 671
10 2000 r_args 337 | 14
2000 0 665
10 5000 r_args 207 | 14
5000 0 661
50 2000 r_args 337 | 73
2000 0 660
10 2000 r_args 207 | 14
2000 0 657
50 5000 apache_request_param 337 | 74
5000 0 647
50 2000 r_args 207 | 75
2000 0 645
10 5000 r_args 337 | 15
5000 0 627
50 5000 r_args 337 | 81
5000 0 601
I'll update this and other benchmarks. Something that should be done
once in a while since the software's performance tend to change over the
time :)
I'll probably run many more tests and build graphs, so it'll be much
easier to see what's happening, than from looking at many numbers.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::args vs Apache::Request speed
Posted by mark warren bracher <br...@citysearch.com>.
I didn't ever actually see a post with newer numbers, so here goes......
I tested the same 50 clients/5000 requests as stas' test in the guide.
one pass with 2 uri params; another with 26. naturally I ran it all on
a server big (and quiescent) enough to handle the 50 concurrent
requests. I left out CGI since we already know it is slow.
/test/params and /test/args are mod_perl handlers (I don't use
Apache::Registry for anything) ParamsTest and ArgsTest respectively.
the code for both handlers and the relevant pieces of ab output are
pasted in below.
-------------------------------------------------------------
name query_length | avtime completed failed rps
-------------------------------------------------------------
apache_args 25 | 33.77 5000 0 1481
apache_request 25 | 33.17 5000 0 1507
apache_args 337 | 43.51 5000 0 1141
apache_request 337 | 45.31 5000 0 1103
--------------------------------------------------------------
Non-varying sub-test parameters:
--------------------------------------------------------------
concurrency : 50
connections : 5000
so $apr->param is marginally faster than $r->args for the shorter query,
marginally slower for the longer one. I think this may be because we
can return the full hash $r->args whereas we need to map over
$apr->param to get a hash (so param gets called three times for the
short query, 27 times for the larger one). still, much closer numbers
than the former test...
- mark
package ParamsTest;
use strict;
use Apache;
use Apache::Constants qw( OK );
use Apache::Request;
sub handler {
my $r = Apache::Request->new( shift );
$r->send_http_header( 'text/plain' );
my %args = map { $_ => $r->param( $_ ) } $r->param();
$r->print( join( "\n",
map { join( '',
$_ , ' => ' , $args{$_}
) }
keys %args
)
);
return OK;
}
1;
package ArgsTest;
use strict;
use Apache;
use Apache::Constants qw( OK );
sub handler {
my $r = shift;
$r->send_http_header( 'text/plain' );
my %args = $r->args();
$r->print( join( "\n",
map { join( '',
$_ , ' => ' , $args{$_}
) }
keys %args
)
);
return OK;
}
1;
Document Path: /test/params?a=eeeeeeeeee&b=eeeeeeeeee
Document Length: 31 bytes
Concurrency Level: 50
Time taken for tests: 3.317 seconds
Complete requests: 5000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 883520 bytes
HTML transferred: 155620 bytes
Requests per second: 1507.39 [#/sec] (mean)
Time per request: 33.17 [ms] (mean)
Time per request: 0.66 [ms] (mean, across all concurrent requests)
Transfer rate: 266.36 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 5 1.9 5 16
Processing: 14 27 4.6 27 50
Waiting: 9 27 4.7 27 49
Total: 14 32 3.7 32 54
Document Path: /test/args?a=eeeeeeeeee&b=eeeeeeeeee
Document Length: 31 bytes
Concurrency Level: 50
Time taken for tests: 3.377 seconds
Complete requests: 5000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 883168 bytes
HTML transferred: 155558 bytes
Requests per second: 1480.60 [#/sec] (mean)
Time per request: 33.77 [ms] (mean)
Time per request: 0.68 [ms] (mean, across all concurrent requests)
Transfer rate: 261.52 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 5 1.8 5 18
Processing: 12 27 4.5 28 63
Waiting: 8 27 4.5 27 63
Total: 12 32 3.7 32 65
Document Path:
/test/params?a=eeeeeeeeee&b=eeeeeeeeee&c=eeeeeeeeee&d=eeeeeeeeee&e=eeeeeeeeee&f=eeeeeeeeee&g=eeeeeeeeee&h=eeeeeeeeee&i=eeeeeeeeee&j=eeeeeeeeee&k=eeeeeeeeee&l=eeeeeeeeee&m=eeeeeeeeee&n=eeeeeeeeee&o=eeeeeeeeee&p=eeeeeeeeee&q=eeeeeeeeee&r=eeeeeeeeee&s=eeeeeeeeee&t=eeeeeeeeee&u=eeeeeeeeee&v=eeeeeeeeee&w=eeeeeeeeee&x=eeeeeeeeee&y=eeeeeeeeee&z=eeeeeeeeee
Document Length: 415 bytes
Concurrency Level: 50
Time taken for tests: 4.531 seconds
Complete requests: 5000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 2810640 bytes
HTML transferred: 2082885 bytes
Requests per second: 1103.51 [#/sec] (mean)
Time per request: 45.31 [ms] (mean)
Time per request: 0.91 [ms] (mean, across all concurrent requests)
Transfer rate: 620.31 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 7 2.9 6 22
Processing: 18 37 11.2 36 496
Waiting: 12 36 11.1 36 495
Total: 18 44 10.8 43 501
Document Path:
/test/args?a=eeeeeeeeee&b=eeeeeeeeee&c=eeeeeeeeee&d=eeeeeeeeee&e=eeeeeeeeee&f=eeeeeeeeee&g=eeeeeeeeee&h=eeeeeeeeee&i=eeeeeeeeee&j=eeeeeeeeee&k=eeeeeeeeee&l=eeeeeeeeee&m=eeeeeeeeee&n=eeeeeeeeee&o=eeeeeeeeee&p=eeeeeeeeee&q=eeeeeeeeee&r=eeeeeeeeee&s=eeeeeeeeee&t=eeeeeeeeee&u=eeeeeeeeee&v=eeeeeeeeee&w=eeeeeeeeee&x=eeeeeeeeee&y=eeeeeeeeee&z=eeeeeeeeee
Document Length: 415 bytes
Concurrency Level: 50
Time taken for tests: 4.381 seconds
Complete requests: 5000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 2808960 bytes
HTML transferred: 2081640 bytes
Requests per second: 1141.29 [#/sec] (mean)
Time per request: 43.81 [ms] (mean)
Time per request: 0.88 [ms] (mean, across all concurrent requests)
Transfer rate: 641.17 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 7 3.0 7 35
Processing: 13 36 6.5 35 86
Waiting: 8 35 6.5 35 86
Total: 13 42 5.6 42 90
Stas Bekman wrote:
> Joe Schaefer wrote:
>> Right- param() was rewritten as XS about 6-8 months ago; since then
>> I've benchmarked it a few times and found param() to be a bit faster than
>> args(). We'll be releasing a 1.0 version of libapreq as soon as Jim
>> approves of the current CVS version. Here's what I got using it on
>> your benchmark (some differences: the tests were run against localhost
>> running perl 5.00503 + mod_perl 1.26 + apache 1.3.22 and using Perl
>> handlers instead of Apache::RegistryLoader scripts):
>
> Great! Now we have an even broader benchmark. Please tell me when 1.0 is
> released (in case I get carried away with other things and don't notice
> the announce) and I'll make sure to update my benchmarking package,
> re-run the benchmarks and correct the results in the guide.
>
> Thanks Joe!
Re: Apache::args vs Apache::Request speed
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>Well, I've run the benchmark and it wasn't the case. Did it change
>>recently? Or do you think that the benchmark is not fair?
>>
>>we are talking about this item
>>http://perl.apache.org/guide/performance.html#Apache_args_vs_Apache_Request
>>
>
> Right- param() was rewritten as XS about 6-8 months ago; since then
> I've benchmarked it a few times and found param() to be a bit faster than
> args(). We'll be releasing a 1.0 version of libapreq as soon as Jim
> approves of the current CVS version. Here's what I got using it on
> your benchmark (some differences: the tests were run against localhost
> running perl 5.00503 + mod_perl 1.26 + apache 1.3.22 and using Perl
> handlers instead of Apache::RegistryLoader scripts):
Great! Now we have an even broader benchmark. Please tell me when 1.0 is
released (in case I get carried away with other things and don't notice
the announce) and I'll make sure to update my benchmarking package,
re-run the benchmarks and correct the results in the guide.
Thanks Joe!
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Apache::args vs Apache::Request speed
Posted by John Siracusa <si...@mindspring.com>.
On 1/27/02 3:34 PM, Joe Schaefer wrote:
> param() was rewritten as XS about 6-8 months ago; since then I've benchmarked
> it a few times and found param() to be a bit faster than args(). We'll be
> releasing a 1.0 version of libapreq as soon as Jim approves of the current CVS
> version.
Did I just read that there's a new version of libapreq coming? If so, will
it:
a) eliminate the current confusion between
J/JI/JIMW/libapreq-0.33.tar.gz
and
D/DO/DOUGM/libapreq-0.31.tar.gz
by creating a unified libapreq distribution with a version number greater
than both of the above, and
b) actually work in Mac OS X (please please please!)
(See: http://archive.develooper.com/macosx@perl.org/msg01124.html)
-John
Re: Apache::args vs Apache::Request speed
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Well, I've run the benchmark and it wasn't the case. Did it change
> recently? Or do you think that the benchmark is not fair?
>
> we are talking about this item
> http://perl.apache.org/guide/performance.html#Apache_args_vs_Apache_Request
Right- param() was rewritten as XS about 6-8 months ago; since then
I've benchmarked it a few times and found param() to be a bit faster than
args(). We'll be releasing a 1.0 version of libapreq as soon as Jim
approves of the current CVS version. Here's what I got using it on
your benchmark (some differences: the tests were run against localhost
running perl 5.00503 + mod_perl 1.26 + apache 1.3.22 and using Perl
handlers instead of Apache::RegistryLoader scripts):
Stas's strings:
my $query = [
join("&", map {"$_=".'e' x 10} ('a'..'b')),
join("&", map {"$_=".'e' x 10} ('a'..'z')),
];
Joe's strings:
%Q = qw/ one alpha two beta three gamma four delta /;
my $query = [
join("&", map "$_=$Q{$_}", keys %Q),
join("&", map "$_=".escape($_), %Q),
];
Stas's Query Joe's Query
short long short long
table 124 91 119 112
args 125 93 116 110
do 124 103 121 118
param 132 106 128 123
noparse 138 136 133 131
REQUESTS PER SECOND
Here I used ab with concurrency = 1 to avoid "complications",
but that shouldn't make a difference if we're talking subroutine
performance. The real disappointment here is handler_table,
which would be the fastest if perl's tied hash implementation
didn't suck so badly. IMO perl's performance for tied-variable
access is shameful, but apparently the problem is unfixable in
perl5.
HANDLERS:
sub handler_args {
my $r = shift;
my %args = $r->args;
$r->send_http_header('text/plain');
print join "\n", %args;
}
sub handler_table {
my $r = Apache::Request->new(shift);
my %args = %{ $r->param };
$r->send_http_header('text/plain');
print join "\n", %$args;
}
sub handler_do {
my $r = Apache::Request->new(shift);
my args; $r->param->do( sub {$args{$_[0]}=$_[1];1} );
$r->send_http_header('text/plain');
print join "\n", %$args;
}
sub handler_param {
my $r = Apache::Request->new(shift);
my %args = map +( $_ => $r->param($_) ), $r->param;
$r->send_http_header('text/plain');
print join "\n", %args;
}
sub handler_noparse {
my $r = shift;
$r->send_http_header('text/plain');
print "OK";
}
--
Joe Schaefer