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=ee&b=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=ee&b=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=ee&b=ee&c=ee&d=ee&e=ee&f=ee&g=ee&h=ee&i=ee&j=ee&k=ee&l=ee&m=ee&n=ee&o=ee&p=ee&q=ee&r=ee&s=ee&t=ee&u=ee&v=ee&w=ee&x=ee&y=ee&z=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)
Re: haunting variable values ? nested subs : cookies
we were seeing something similiar with old/variant cookie data, turned
out to be the difference between
$r->headers_out->add('Set-Cookie'=>$cookie);
and
$r->headers_out->set('Set-Cookie'=>$cookie);
you show your code for generating the cookie, but not setting it, so I
have no way of knowing if this is the same issue...
- mark
Don Fike wrote:
> Hello,
>
> I have a fairly simple/straight forward scripts which displays a form. I
> set a cookie to store name and email for the submitting user just in case
> they return. Yet when I set the cookie it gets set for all, from anywhere,
> not just me on my desktop. Sometimes a previous cookie pops up. The
> results aren't entirely consistent. I am unsure if this is a mod_perl
> problem, a nested subroutine problem, or a cookie problem. There are
> actually 3 scripts and a lib file that either display the form, process it,
> or do other process' not directly related to the form or cookies.
>
> I am using;
> Perl 5.6
> mod_perl 1.24
> CGI.pm 2.71
> I set the cookie by;
>
> my %user;
> $user{'username'} = $q->param('author');
> $user{'useremail'} = $q->param('email');
>
> my $cookie = $q->cookie(-name=>'user',
> -value=>\%user,
> -path=>'/threads',
> -expires=>'+1y');
>
> I retrieve the cookie by;
>
> my %user;
> %user = $q->cookie('user');
>
> I thought I might have had the nested subroutine problem discussed in the
> guide and moved my subroutines to a library file. This didn't help, but I
> likely copy/pasted the problem into my new lib.pl file.
>
> I know my description is rather cryptic but if you recognize a problem
> please let me know.
>
> Thanks,
>
> ---
> Don Fike
> UTK/ICL
> [EMAIL PROTECTED]
> 865-974-0293
> ---
Re: perl's memory leak
it seems as if most (if not all) the techniques for checking the size of the current process are _very_ platform specific. on linux you can use Apache::SizeLimit::linux_size_check which is just parsing /proc/self/status. - mark Stas Bekman wrote: > On Thu, 7 Dec 2000 [EMAIL PROTECTED] wrote: > > >> The output I get is >> >> used memory = 0 >> used memory = 0 >> used memory = 0 >> used memory = 0 >> used memory = 0 > > > I get the same under perl 5.6.0 on linux, looks like BSD::Resource doesn't > work there :( Anyone? > > Use gtop instead (if you have it): > use GTop (); > print GTop->new->proc_mem($$)->size,"\n"; [snip] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] (just a bit) CPAN upgrade auto installation of 5.6
Bernhard Graf wrote: > [EMAIL PROTECTED] wrote: > > Just want to gripe and warn others about the fact that if you elect to > > upgrade CPAN.pm it also installs perl 5.6 > > > > Don't go and get coffee if you MCPAN the upgrade! > > This does not seem to be the case anymore with the recent version of > CPAN.pm (the "real" 1.54 - not the 1.53). Tried it out yesterday. it is the case if you issue an install Bundle::CPAN as MCPAN recommends you do if it sees a new version. if you simply install CPAN it works quite well. appears perl-5.6 is a pre-req for the latest Bundle::CPAN? hard to believe... - mark -- Imagine if every Thursday your shoes exploded as you tied them the usual way. This happens to us all the time with Microsoft software, and nobody thinks of complaining. -- Unknown
