Re: Apache::args vs Apache::Request speed
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 failedrps - 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 failedrps 505000 apache_request_param 25 | 53 5000 0900 502000 apache_request_param 25 | 54 2000 0884 505000 r_args 25 | 55 5000 0879 502000 apache_request_param 105 | 54 2000 0879 105000 apache_request_param 25 | 10 5000 0878 505000 r_args105 | 55 5000 0876 102000 r_args105 | 10 2000 0869 505000 apache_request_param 105 | 56 5000 0865 105000 apache_request_param 105 | 10 5000 0855 105000 r_args 25 | 11 5000 0850 102000 apache_request_param 105 | 11 2000 0836 102000 r_args 25 | 11 2000 0835 102000 apache_request_param 25 | 11 2000 0832 502000 r_args 25 | 58 2000 0827 105000 r_args105 | 11 5000 0810 505000 apache_request_param 207 | 64 5000 0754 502000 apache_request_param 337 | 64 2000 0750 102000 apache_request_param 207 | 12 2000 0749 102000 apache_request_param 337 | 12 2000 0749 502000 apache_request_param 207 | 64 2000 0749 105000 apache_request_param 207 | 12 5000 0746 502000 r_args105 | 64 2000 0744 105000 apache_request_param 337 | 12 5000 0732 505000 r_args207 | 72 5000 0671 102000 r_args337 | 14 2000 0665 105000 r_args207 | 14 5000 0661 502000 r_args337 | 73 2000 0660 102000 r_args207 | 14 2000 0657 505000 apache_request_param 337 | 74 5000 0647 502000 r_args207 | 75 2000 0645 10
Re: Apache::args vs Apache::Request speed
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 failedrps
-
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=eeb=ee
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 51.9 516
Processing:14274.6 2750
Waiting:9274.7 2749
Total: 14323.7 3254
Document Path: /test/args?a=eeb=ee
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: 18 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 51.8 518
Processing:12274.5 2863
Waiting:8274.5 2763
Total: 12323.7 3265
Document Path:
/test/params?a=eeb=eec=eed=eee=eef=eeg=eeh=eei=eej=eek=eel=eem=een=eeo=eep=eeq=eer=ees=eet=eeu=eev=eew=eex=eey=eez=ee
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:
Re: Apache::args vs Apache::Request speed
Ian Ragsdale [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Heyas, JSWould someone PLEASE volunteer to try to compile and test JSapache+mod_perl libapreq on OS/X using the experimental JScode I posted there? Even if you can't get it working, JSANY feedback about what happened when you tried would be JSVERY 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/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: Apache::args vs Apache::Request speed
On 2/1/02 2:21 PM, Joe Schaefer [EMAIL PROTECTED] wrote: Ian Ragsdale [EMAIL PROTECTED] 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
Re: Apache::args vs Apache::Request speed
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
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
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
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 [EMAIL PROTECTED] 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, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: Stas Bekman [EMAIL PROTECTED] 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
John Siracusa [EMAIL PROTECTED] 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, [EMAIL PROTECTED] 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
Joe Schaefer wrote: Stas Bekman [EMAIL PROTECTED] 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:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Apache::args vs Apache::Request speed
Stas Bekman [EMAIL PROTECTED] 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
Stas Bekman [EMAIL PROTECTED] 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 QueryJoe's Query
short long short long
table 124 91119 112
args 125 93116 110
do 124 103121 118
param 132 106128 123
noparse138 136133 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
Re: Apache::args vs Apache::Request speed
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:[EMAIL PROTECTED]/msg01124.html) -John
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:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
