Re: what's the apache mod_perl speedup factor?
Let me be more descriptive. IO.xs has some useful features.
Most of the IO::*.pm modules do not, especially Handle and File.
Here's all you need from the low-level IO.xs stuff, the things that
aren't in straight Perl (although some can be done, but less
conveniently):
require IO::Handle;
my @IMPORTS;
BEGIN { @IMPORTS = (qw/ blocking clearerr error formline getpos
setbuf setpos setvbuf sync untaint / ); }
use subs @IMPORTS;
for my $func (@IMPORTS) {
no strict 'refs';
no warnings; # squelch wicked coercion of ($;$) in IO.xs's io_blocking()
*$func = \&{"IO::Handle::$func"};
}
untaint(*STDIN);
formline(*STDERR, "^" . ("<" x 72) . "~~\n", "can this work " x 40);
Or, if you like, somewhat more robustly even than silly Mr
I-can't-do-compile-time-checks Method calls:
require FileHandle;
{
no warnings; # next line predeclares w/ context coercer of (@)
use subs qw/ blocking clearerr error formline getpos setbuf setpos
setvbuf sync untaint /;
sub clearerr(*) { shift->clearerr }
sub blocking(*,$) { shift->blocking(@_) }
sub error(*){ shift->error }
sub formline(*$@) { shift->formline(@_) }
sub getpos(*) { shift->getpos }
sub setbuf(*) { shift->setbuf(@_) }
sub setpos(*$) { shift->setpos(@_) }
sub setvbuf(*$$){ shift->setvbuf(@_)}
sub sync(*) { shift->sync }
sub untaint(*) { shift->untaint}
}
untaint(STDIN);
formline(STDERR, "^" . ("<" x 72) . "~~\n", "can this work " x 40);
That's not to say that IO::Socket isn't nice to have. But this
is usually all you need of it:
require IO::Socket;
sub inet_socket { IO::Socket::INET->new(@_) }
*Mailer = inet_socket("localhost:smtp");
print scalar ;
Select Saver isn't bad either.
--tom
Re: what's the apache mod_perl speedup factor?
>> Huh? No, it doesn't. >I stand corrected. OO interface to _many_ _I/O_ system calls. >Better, or do you object to the "needed" part? Rather. It's nearly completely gratuitous. --tom
Re: what's the apache mod_perl speedup factor?
Tom Christiansen <[EMAIL PROTECTED]> writes: > >IO provides a needed, though costly, OO interface to > >most system calls. > > Huh? No, it doesn't. I stand corrected. OO interface to _many_ _I/O_ system calls. Better, or do you object to the "needed" part? Chip -- Chip Turner [EMAIL PROTECTED] ZFx, Inc. www.zfx.com PGP key available at wwwkeys.us.pgp.net
Re: what's the apache mod_perl speedup factor?
>IO provides a needed, though costly, OO interface to >most system calls. Huh? No, it doesn't. --tom
Re: what's the apache mod_perl speedup factor?
Tom Christiansen <[EMAIL PROTECTED]> writes:
> I would like to console people against using the fancy IO
> modules, or at least, not to do so without knowing what they're
> getting into. Look at where we are now:
>
> % wc `perl -MIO -e 'print join("\n", sort values %INC, "")'`
[snip]
> The following numbers show memory sizes (virtual and resident) for
> v5.6 of Perl on four different operating systems, The three calls
> each are without any modules, with just -MCGI, and with -MIO (never
> with both):
>
> OpenBSD FreeBSD Redhat Solaris
> vsz rss vsz rss vsz rssvszrss
> Raw Perl736 772 832 12082412 9802928 2272
> w/ CGI 1220 14641308 18282972 17683616 3232
> w/ IO 2292 25802456 30164080 28685384 4976
>
> Anybody who's thinking of choosing one of these might do well to
> stare at those numbers for a while.
This is mitigated somewhat by loading the modules once on a cold start
and letting them propogate to child httpd's via fork. This helps with
the memory and startup time. It's unfortunate that those modules are
so large, but with perl and websites the tradeoff is usually memory
for performance. Since it's easier to double the RAM of a system than
to double the CPU speed, many consider it a fair trade. :)
Of course, I suspect you knew that, but maybe not everyone does.
I am curious; do you advocate not using such modules, or do you
advocate a simpler API of some sorts? Perl sucks memory, no two ways
about it. CGI.pm is huge and tries to do everything, which is rarely
a good thing. IO provides a needed, though costly, OO interface to
most system calls. What alternatives are there really besides
rewriting and breaking those modules up, as has partially been done
with some Apache modules vs CGI.pm. I'm not aware of any similar
attacks on IO.
Chip
--
Chip Turner [EMAIL PROTECTED]
ZFx, Inc. www.zfx.com
PGP key available at wwwkeys.us.pgp.net
Re: what's the apache mod_perl speedup factor?
>tom, my direct reply to you bounced, but this should probably be on the
>list anyhow...
> - Transcript of session follows -
>... while talking to mail.perl.com.:
MAIL From:<[EMAIL PROTECTED]>
><<< 550 Your site is blacklisted as a spam haven.
>554 <[EMAIL PROTECTED]>... Service unavailable
Hm... you must be using an open relay. I don't have covalent listed
here. I see a uunet bounce, which is not unlikely. They're terrible,
because they sell to everyone, and then don't enforce any AUP on
their downstream resellers.
I don't tend to trust timing under a second. The quantum fluctuations
in the universe are too hard to predict. :-)
I would like to console people against using the fancy IO
modules, or at least, not to do so without knowing what they're
getting into. Look at where we are now:
% wc `perl -MIO -e 'print join("\n", sort values %INC, "")'`
124 6964166 /usr/local/lib/perl5/5.6.0/Carp.pm
5802465 17661 /usr/local/lib/perl5/5.6.0/Class/Struct.pm
4001495 10455 /usr/local/lib/perl5/5.6.0/Cwd.pm
3131589 10377 /usr/local/lib/perl5/5.6.0/Exporter.pm
225 7845651 /usr/local/lib/perl5/5.6.0/Exporter/Heavy.pm
92 3392813 /usr/local/lib/perl5/5.6.0/File/Spec.pm
4421574 10276 /usr/local/lib/perl5/5.6.0/File/Spec/Unix.pm
115 3982806 /usr/local/lib/perl5/5.6.0/File/stat.pm
4061350 10265 /usr/local/lib/perl5/5.6.0/IO/Socket/INET.pm
143 4293075 /usr/local/lib/perl5/5.6.0/IO/Socket/UNIX.pm
7168 24137 178650 /usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd/Config.pm
23010525995 /usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd/Errno.pm
222 7255216 /usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd/Fcntl.pm
47 101 669 /usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd/IO.pm
239 7695005 /usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd/IO/Dir.pm
169 5493956 /usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd/IO/File.pm
5942180 14772 /usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd/IO/Handle.pm
252 7555375 /usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd/IO/Pipe.pm
77 2351709 /usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd/IO/Seekable.p
m
4281419 10219 /usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd/IO/Socket.pm
4521401 10554 /usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd/Socket.pm
127 4733554 /usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd/XSLoader.pm
52 1611050 /usr/local/lib/perl5/5.6.0/SelectSaver.pm
139 5413754 /usr/local/lib/perl5/5.6.0/Symbol.pm
161 6094081 /usr/local/lib/perl5/5.6.0/Tie/Hash.pm
109 3902479 /usr/local/lib/perl5/5.6.0/strict.pm
79 3702589 /usr/local/lib/perl5/5.6.0/vars.pm
3181124 11975 /usr/local/lib/perl5/5.6.0/warnings.pm
30 85 722 /usr/local/lib/perl5/5.6.0/warnings/register.pm
13733 48195 349869 total
Incredible.
Moreover, that requires 116 happy trips through the kernel's namei().
It syscalls open() a remarkable 57 times, 17 of which failed but
leaving 38 that were successful. It also syscalled read() a curiously
identical 57 times, ingesting a total of 180,265 plump bytes. To
top it off, this INCREASES YOUR RESIDENT SET SIZE BY TWO MEGABYTES!
Happy mallocking, Oh, and the answer you're looking for on CGI.pm is:
% wc `perl -MCGI -le 'print for values %INC'`
13686920 43710 /usr/local/lib/perl5/5.6.0/overload.pm
6481 26122 200840 /usr/local/lib/perl5/5.6.0/CGI.pm
7849 33042 244550 total
You have 16 trips through namei, 7 successful opens, 2 unsuccessful ones,
and 213k of data read in.
The following numbers show memory sizes (virtual and resident) for
v5.6 of Perl on four different operating systems, The three calls
each are without any modules, with just -MCGI, and with -MIO (never
with both):
OpenBSD FreeBSD Redhat Solaris
vsz rss vsz rss vsz rssvszrss
Raw Perl736 772 832 12082412 9802928 2272
w/ CGI 1220 14641308 18282972 17683616 3232
w/ IO 2292 25802456 30164080 28685384 4976
Anybody who's thinking of choosing one of these might do well to
stare at those numbers for a while.
--tom
Re: what's the apache mod_perl speedup factor?
tom, my direct reply to you bounced, but this should probably be on the list anyhow... - Transcript of session follows - ... while talking to mail.perl.com.: >>> MAIL From:<[EMAIL PROTECTED]> <<< 550 Your site is blacklisted as a spam haven. 554 <[EMAIL PROTECTED]>... Service unavailable On Fri, 31 Mar 2000, Tom Christiansen wrote: > Any rough rule-of-thumb scaling factor for how much faster running > an averaged sized CGI script under mod_perl is compared with firing > it up each time? For example, 2x? 5x? 10x? 20x? 40x? Obviously this > depends on a lot of factors, but perhaps there's something on can say > that's more generally true than it is false? > > --tom > there's an attempt at benchmarking mod_perl vs. foo here: http://www.chamas.com/bench/index.html and a simple test you can run in the mod_perl-x.xx directory: % ../apache-1.3/src/httpd -d `pwd`/t -f `pwd`/t/conf/httpd.conf % perl benchmark/lwp-simple.pod Benchmark: timing 50 iterations of cgi, perl... cgi: 16 wallclock secs ( 0.63 usr + 0.10 sys = 0.73 CPU) @ 68.49/s (n=50) perl: 1 wallclock secs ( 0.31 usr + 0.05 sys = 0.36 CPU) @ 138.89/s (n=50) (warning: too few iterations for a reliable count) % kill `cat t/logs/httpd.pid` that runs 50 requests each to /cgi-bin (mod_cgi) and /perl (mod_perl) for the same script, t/net/perl/cgi.pl i don't have enough data to support a statement that mod_perl is x times faster that mod_cgi, like you say, it depends on a lot of factors.
