You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Matt Arnold <ma...@novia.net> on 2000/03/30 05:34:39 UTC
performance mongers: since when is using CGI.pm or Apache::Registry dishonorable?
Many messages on this list perpetuate the notion that usage of CGI.pm and
Apache::Registry is for beginners. Popular opinion is that you're not a
leet mod_perl h@x0r until you wean yourself from CGI.pm and Apache::Registry
and "graduate" to the Apache API. With this in mind, there have been many
messages over the years making blanket statements along the lines of "CGI.pm
is evil" and/or "Apache::Registry sux". I'm trying to identify the source
of this disatisfaction. While it may seem that my intent is to start the
ultimate, end-all CGI.pm/Apache::Registry flame war, please be assured that
I am interested in ferreting out the real issues. :-)
Anyway, in hope of generating some debate, I'll make some (potentially
inflammatory) assertions:
1. An Apache handler doesn't mean CGI.pm *ISN'T* in use
The "Apache::Registry sux" crowd claims I should forgo Apache::Registry and
write handlers instead. Okay, here's my handler:
# in httpd.conf
<Location /foo>
SetHandler perl-script
PerlHandler Apache::Foo
</Location>
package Apache::Foo;
use strict;
use CGI ();
sub handler {
my $q = CGI->new;
print $q->header;
print "Hello World\n";
200;
}
1;
Satisfied? No Apache::Registry in use here. Am I a l33t h@x0r now? No?
Why not? Oh, so when the zealots say, "Apache::Registry sux, write handlers
instead" they really mean I should be using the Apache API instead of
CGI.pm. I see.
I have another beef with the "CGI emulation sux, avoid Apache::Registry"
crowd. And that is:
2. Just because you don't use Apache::Registry doesn't mean you're not doing
CGI emulation (*gasp*)
What exactly is this "evil, bloated, slow CGI emulation" that everyone's
trying to avoid? Is it the overheard of setting up all the environment
variables? Well, gee whiz, regular handlers do this too unless you tell
them not to. Try the following exercise:
<Location /env>
#PerlSetupEnv Off # try first without; then try with PerlSetupEnv Off
SetHandler perl-script
PerlHandler Apache::Env
</Location>
package Apache::Env;
use strict;
use Data::Dumper qw(Dumper);
sub handler {
my $r = shift;
$r->content_type('text/plain');
$r->send_http_header;
$r->print(Dumper(\%ENV));
200;
}
1;
So let's not be so quick to curse Apache::Registry for it's "slow" CGI
emulation. Your "fast" handlers are probably doing the same thing
unbeknownst to you.
Another assertion:
3. Using Apache::Registry doesn't necessarily mean CGI.pm is at use
It seems the "Apache::Registry sux" crowd dislikes Apache::Registry because
it implies that CGI.pm is in use. Perhaps their real gripe is one should
use the Apache API instead of CGI.pm's methods. So how would they feel
about this:
# in httpd.conf
<Location /bar>
PerlSetupEnv Off # we don't need no stinking ENV
SetHandler perl-script
PerlHandler Apache::Registry # or Apache::RegistryNG->handler
Options +ExecCGI
</Location>
#!/usr/local/bin/perl -w
use strict;
my $r = Apache->request;
$r->content_type("text/html");
$r->send_http_header;
$r->print("Hi There!");
Does this count? Am I a l33t h@x0r because I used the Apache API? Or am I
still a lamer for using Apache::Registry?
I can hear the hordes out there crying, "Why use Apache::Registry if you're
not using CGI.pm?" Well, perhaps I have a couple hundred scripts and don't
want to maintain several hundred <Location> directives in httpd.conf. Maybe
I like Apache::Registry's convenient way of grabbing my script, wrapping it
into a handler on-the-fly, and serving it up. Isn't this one of the handier
features of Apache::Registry? (Note: I'd like to hear of alternatives to
Apache::Registry[BB|NG] for doing this.)
So maybe Apache::Registry isn't pure evil after all. So perhaps the zealots
clarify their mantra to be simply "CGI.pm sux". That leads us to the next
assertion.
4. Using CGI.pm is smart (aka don't reinvent CGI.pm's HTML methods)
Somewhere along the line, CGI.pm became "bad, evil, and bloated". Many of
you don't want to use CGI.pm for anything. While some of CGI.pm's
functionality can be done more efficiently by other means (i.e.
Apache::Request), CGI.pm's HTML methods have no such high-efficiency
equivalents. Since laziness is one of the primary Perl virtues, isn't it
smart to leverage the work already done in CGI.pm rather than rolling your
own HTML methods? Can't using CGI.pm's HTML methods be considered a "good
thing"?
The recent thread "[ot] How to crypt the way htpasswd does..." serves as an
example of how one can get chastised for failure to use existing code. (See
http://forum.swarthmore.edu/epigone/modperl/nengahker for the thread.) Why
are so many of you quick to ignore this advice? Why is this particular
wheel one so many of you are willing to reinvent? Would the anti-CGI.pm
crowd be more likely to use these HTML functions if they were in their own
(presumably leaner) module unbundled from the "bloated, monolithic" CGI.pm?
With all this in mind, we can finally arrive at...
5. Don't use CGI.pm for what can be done elsewhere, faster
Perhaps this is what most of you performance mongers really mean. Don't use
CGI.pm to do stuff the API can do -- use the Apache API or Apache::Request
instead. And be sure to set "PerlSetupEnv Off" unless you need it. This
seems like good advice. See how easy it is to give out good advice without
any disparaging comments against CGI.pm or Apache::Registry. :-)
So I'm hoping you'll agree that it's still possible to have a
highly-efficient system and be a leet mod_perl h@x0r while still using
CGI.pm and Apache::Registry. Leveraging CGI.pm's HTML functions is smarter
than reinventing your own. And the use of Apache::Registry doesn't
necessarily mean CGI.pm or "CGI emulation" are in use.
Thanks in advance for your flames, er... replies.
Matt
P.S. The terms l33t h@x0r, zealot, performance monger, and code wanker are
intended to be complimentary -- not inflammatory. (Well, okay, code wanker
is intended to be inflammatory, but I never used that term.)
P.P.S. I should have some benchmarks soon showing CGI.pm vs.
Apache::Request, handler vs. Apache::Registry vs. Apache::RegistryBB,
PerlSetupEnv Off vs. On, etc.
Re: performance mongers: since when is using CGI.pm or Apache::Registry
dishonorable?
Posted by Cliff Rayman <cl...@genwax.com>.
i think anyone who is not writing their own custom kernel in direct machine code
to handle all requests directly from the NIC is a lamer. but that's just mee.
sorry for the extra e on the end of mee but 00000111 is too many switches to
throw
just to get a backspace. :-)
cliff rayman
genwax.com
Matt Arnold wrote:
> Many messages on this list perpetuate the notion that usage of CGI.pm and
> Apache::Registry is for beginners. Popular opinion is that you're not a
> leet mod_perl h@x0r until you wean yourself from CGI.pm and Apache::Registry
> and "graduate" to the Apache API. With this in mind, there have been many
> messages over the years making blanket statements along the lines of "CGI.pm
> is evil" and/or "Apache::Registry sux". I'm trying to identify the source
> of this disatisfaction. While it may seem that my intent is to start the
> ultimate, end-all CGI.pm/Apache::Registry flame war, please be assured that
> I am interested in ferreting out the real issues. :-)
>
> Anyway, in hope of generating some debate, I'll make some (potentially
> inflammatory) assertions:
>
> 1. An Apache handler doesn't mean CGI.pm *ISN'T* in use
>
> The "Apache::Registry sux" crowd claims I should forgo Apache::Registry and
> write handlers instead. Okay, here's my handler:
>
> # in httpd.conf
> <Location /foo>
> SetHandler perl-script
> PerlHandler Apache::Foo
> </Location>
>
> package Apache::Foo;
> use strict;
> use CGI ();
> sub handler {
> my $q = CGI->new;
> print $q->header;
> print "Hello World\n";
> 200;
> }
> 1;
>
> Satisfied? No Apache::Registry in use here. Am I a l33t h@x0r now? No?
> Why not? Oh, so when the zealots say, "Apache::Registry sux, write handlers
> instead" they really mean I should be using the Apache API instead of
> CGI.pm. I see.
>
> I have another beef with the "CGI emulation sux, avoid Apache::Registry"
> crowd. And that is:
>
> 2. Just because you don't use Apache::Registry doesn't mean you're not doing
> CGI emulation (*gasp*)
>
> What exactly is this "evil, bloated, slow CGI emulation" that everyone's
> trying to avoid? Is it the overheard of setting up all the environment
> variables? Well, gee whiz, regular handlers do this too unless you tell
> them not to. Try the following exercise:
>
> <Location /env>
> #PerlSetupEnv Off # try first without; then try with PerlSetupEnv Off
> SetHandler perl-script
> PerlHandler Apache::Env
> </Location>
>
> package Apache::Env;
> use strict;
> use Data::Dumper qw(Dumper);
> sub handler {
> my $r = shift;
> $r->content_type('text/plain');
> $r->send_http_header;
> $r->print(Dumper(\%ENV));
> 200;
> }
> 1;
>
> So let's not be so quick to curse Apache::Registry for it's "slow" CGI
> emulation. Your "fast" handlers are probably doing the same thing
> unbeknownst to you.
>
> Another assertion:
>
> 3. Using Apache::Registry doesn't necessarily mean CGI.pm is at use
>
> It seems the "Apache::Registry sux" crowd dislikes Apache::Registry because
> it implies that CGI.pm is in use. Perhaps their real gripe is one should
> use the Apache API instead of CGI.pm's methods. So how would they feel
> about this:
>
> # in httpd.conf
> <Location /bar>
> PerlSetupEnv Off # we don't need no stinking ENV
> SetHandler perl-script
> PerlHandler Apache::Registry # or Apache::RegistryNG->handler
> Options +ExecCGI
> </Location>
>
> #!/usr/local/bin/perl -w
> use strict;
> my $r = Apache->request;
> $r->content_type("text/html");
> $r->send_http_header;
> $r->print("Hi There!");
>
> Does this count? Am I a l33t h@x0r because I used the Apache API? Or am I
> still a lamer for using Apache::Registry?
>
> I can hear the hordes out there crying, "Why use Apache::Registry if you're
> not using CGI.pm?" Well, perhaps I have a couple hundred scripts and don't
> want to maintain several hundred <Location> directives in httpd.conf. Maybe
> I like Apache::Registry's convenient way of grabbing my script, wrapping it
> into a handler on-the-fly, and serving it up. Isn't this one of the handier
> features of Apache::Registry? (Note: I'd like to hear of alternatives to
> Apache::Registry[BB|NG] for doing this.)
>
> So maybe Apache::Registry isn't pure evil after all. So perhaps the zealots
> clarify their mantra to be simply "CGI.pm sux". That leads us to the next
> assertion.
>
> 4. Using CGI.pm is smart (aka don't reinvent CGI.pm's HTML methods)
>
> Somewhere along the line, CGI.pm became "bad, evil, and bloated". Many of
> you don't want to use CGI.pm for anything. While some of CGI.pm's
> functionality can be done more efficiently by other means (i.e.
> Apache::Request), CGI.pm's HTML methods have no such high-efficiency
> equivalents. Since laziness is one of the primary Perl virtues, isn't it
> smart to leverage the work already done in CGI.pm rather than rolling your
> own HTML methods? Can't using CGI.pm's HTML methods be considered a "good
> thing"?
>
> The recent thread "[ot] How to crypt the way htpasswd does..." serves as an
> example of how one can get chastised for failure to use existing code. (See
> http://forum.swarthmore.edu/epigone/modperl/nengahker for the thread.) Why
> are so many of you quick to ignore this advice? Why is this particular
> wheel one so many of you are willing to reinvent? Would the anti-CGI.pm
> crowd be more likely to use these HTML functions if they were in their own
> (presumably leaner) module unbundled from the "bloated, monolithic" CGI.pm?
>
> With all this in mind, we can finally arrive at...
>
> 5. Don't use CGI.pm for what can be done elsewhere, faster
>
> Perhaps this is what most of you performance mongers really mean. Don't use
> CGI.pm to do stuff the API can do -- use the Apache API or Apache::Request
> instead. And be sure to set "PerlSetupEnv Off" unless you need it. This
> seems like good advice. See how easy it is to give out good advice without
> any disparaging comments against CGI.pm or Apache::Registry. :-)
>
> So I'm hoping you'll agree that it's still possible to have a
> highly-efficient system and be a leet mod_perl h@x0r while still using
> CGI.pm and Apache::Registry. Leveraging CGI.pm's HTML functions is smarter
> than reinventing your own. And the use of Apache::Registry doesn't
> necessarily mean CGI.pm or "CGI emulation" are in use.
>
> Thanks in advance for your flames, er... replies.
>
> Matt
>
> P.S. The terms l33t h@x0r, zealot, performance monger, and code wanker are
> intended to be complimentary -- not inflammatory. (Well, okay, code wanker
> is intended to be inflammatory, but I never used that term.)
>
> P.P.S. I should have some benchmarks soon showing CGI.pm vs.
> Apache::Request, handler vs. Apache::Registry vs. Apache::RegistryBB,
> PerlSetupEnv Off vs. On, etc.
Re: performance mongers: since when is using CGI.pm or Apache::Registry dishonorable?
Posted by Ken Williams <ke...@forum.swarthmore.edu>.
marnold@novia.net (Matt Arnold) wrote:
>I came across poorly in my original message. Some of my wording (e.g. l33t,
>h@x0r, sux, etc.) was a poor attempt at trying to make the message
>entertaining. :-( <Shrug> I feel badly that my poor wording and/or extreme
>tone is getting in the way of the intent. I sincerely want to learn the
>performance issues of CGI.pm and Apache::Registry. I'm sorry for the
>miscommunication. If you find the message too inflammatory, please delete.
Thanks for the clarification.
In general, I find the performance differences between *any* of the various
mod_perl solutions to be of only minor importance. There's not a whole lot of
difference between really fast and super fast, because both are faster than I
really need, and faster than my clients can accept the content anyway.
Of far greater importance is whether you can organize your code well using a
particular solution, whether you can scale your efforts well, and so on. This
means that some people will enjoy the approach of Apache::Registry, others
Apache handler modules, or things like HTML::Mason or HTML::Embperl. Mason is
the tool I like the best, just because I can organize things well and it just
"feels right" to me. But I wouldn't try to change anyone's mind if they liked
a different tool more.
------------------- -------------------
Ken Williams Last Bastion of Euclidity
ken@forum.swarthmore.edu The Math Forum
Re: performance mongers: since when is using CGI.pm or Apache::Registry dishonorable?
Posted by Matt Arnold <ma...@novia.net>.
I came across poorly in my original message. Some of my wording (e.g. l33t,
h@x0r, sux, etc.) was a poor attempt at trying to make the message
entertaining. :-( <Shrug> I feel badly that my poor wording and/or extreme
tone is getting in the way of the intent. I sincerely want to learn the
performance issues of CGI.pm and Apache::Registry. I'm sorry for the
miscommunication. If you find the message too inflammatory, please delete.
Sorry (really),
Matt
Re: performance mongers: since when is using CGI.pm or Apache::Registry dishonorable?
Posted by Perrin Harkins <pe...@primenet.com>.
> Many messages on this list perpetuate the notion that usage of CGI.pm and
> Apache::Registry is for beginners.
CGI.pm is a beautiful hack, and the kind of ultimately flexible program that
could only have been written in perl. Why would you want to avoid CGI.pm?
Because it's slower and uses more memory than Apache::Request, or even
CGI_Lite. There are lighter alternatives to get the HTML generation as
well, but I don't use that so I can't comment on them.
Apache::Registry is a great way to get legacy stuff running under mod_perl
fast. Why avoid Apache::Registry for new projects? Because having your
code wrapped in a subroutine makes life difficult when you want to define
subs of your own. Because many of the problems discussed in the Guide and
mod_perl_traps document are Registry specific. Because you don't want that
stat call on every request and RegistryBB might actually be slower. (It was
for me.) Because run-time calls to eval (which Registry uses to compile
your script) can leak memory in certain situtations. Because it's nice to
control your namespace. Because mod_perl is more than just content
handlers.
But I use it because I like to feel 3l33t. Give me warez, d00dz!
By the way, if you really have several hundred unique handlers that all need
their own <Location> entries, you have bigger fish to fry than filling out
httpd.conf. Most people assign entire directory hierarchies or file
extensions to one handler.
- Perrin
Re: performance mongers: since when is using CGI.pm or Apache::Registry dishonorable?
Posted by Vivek Khera <kh...@kciLink.com>.
>>>>> "dc" == darren chamberlain <da...@boston.com> writes:
dc> Use a perl section in your startup file that loops and reads Locations,
dc> options, and modules from a file or DB. No more ugly typing.
So then how do you add/remove locations easily to a running server?
You have to restart it, I guess... not an optimal solution, really.
Re: performance mongers: since when is using CGI.pm or Apache::Registry dishonorable?
Posted by darren chamberlain <da...@boston.com>.
Use a perl section in your startup file that loops and reads Locations,
options, and modules from a file or DB. No more ugly typing.
darren
Vivek Khera (khera@kciLink.com) said something to this effect:
> >>>>> "DM" == Doug MacEachern <do...@covalent.net> writes:
>
> DM> geez. i don't recall "Apache::Registry vs. pure PerlHandler" or
> DM> "Apache::Request vs. CGI.pm" ever being so harsh.
>
> Personally, I do all my scripting in Apache::Registry. Why? Because
> it is easy, and I don't always have the ability to restart the server
> to update some code or modify the config to add the handler mappings.
> With a bit of careful coding, you avoid any problems referred to here
> before.
>
> My question to all of you who use handlers directly, how do you manage
> all your handler mappings? I've seen it done where you add a
> <Location> mapping for each handler you use, which corresponds to each
> "program" you need. This, in my experience, tends to be error prone
> and results in much cruft in your httpd.conf file.
>
> What other approaches are there? I think having some equivalent of
> Apache::Registry which will automatically dispatch a URI to a handler,
> and suck in the module if necessary would be a useful thing. (Gosh, I
> hope there isn't one already that I've missed .... ;-)
>
> As for CGI.pm being a memory pig, yep... it sure is. I used to use
> CGI::Base and CGI::Request modules extensively, but they seem to have
> started collecting virtual dust and nobody maintains them anymore...
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Vivek Khera, Ph.D. Khera Communications, Inc.
> Internet: khera@kciLink.com Rockville, MD +1-301-545-6996
> PGP & MIME spoken here http://www.kciLink.com/home/khera/
--
Sport is a great leveller, but then so is death.
Re: performance mongers: since when is using CGI.pm or
Apache::Registrydishonorable?
Posted by Vivek Khera <kh...@kciLink.com>.
>>>>> "GB" == Gunther Birznieks <gu...@extropia.com> writes:
GB> Does the size of CGI.pm really matter with mod_perl so much? If the module
GB> is pre-loaded prior to forking, wouldn't the memory for this module tend
GB> to be shared anyway? Or is there still a gradual hit to real memory as
Yes it is shared assuming you do it like this:
use CGI (); CGI->compile(':cgi');
where :cgi might be replaced with whatever tag set you commonly use.
Otherwise CGI.pm pulls in code as it runs, after the forking happens.
Personally, I feel that any memory wasted, despite being shared, is
waste. That's why I only use the CGI interface part of CGI.pm...
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-301-545-6996
PGP & MIME spoken here http://www.kciLink.com/home/khera/
Re: performance mongers: since when is using CGI.pm or Apache::Registry
dishonorable?
Posted by "C. Jon Larsen" <jl...@richweb.com>.
Setup a single appRequestHandler() that uses a hash table to map uris to
functions. Becomes even more useful when you put your library code for
sessions, headers, footers, etc in the wrapper routine.
---------------------------------------------
my $info = {
c jon larsen => 'richweb.com',
email: => 'jlarsen@richweb.com',
wireless: => '+804.307.6939',
};
On Fri, 31 Mar 2000, Shevek wrote:
> On Fri, 31 Mar 2000, Vivek Khera wrote:
>
> > My question to all of you who use handlers directly, how do you manage
> > all your handler mappings? I've seen it done where you add a
> > <Location> mapping for each handler you use, which corresponds to each
> > "program" you need. This, in my experience, tends to be error prone
> > and results in much cruft in your httpd.conf file.
>
> I have a single handler which matches all files, if the file exists
> ($r->finfo and other tests), it returns DECLINED. Else it makes a decision
> in Perl, and dispatches to the relevant handler in Perl. This makes
> loading the Perl script in a server very intensive, a problem which I am
> looking to solve soon.
>
> Ta.
>
> S.
>
> --
> Shevek
> GM/CS/MU -d+ H+>++ s+: !g p2 au0 !a w+++ v-(---) C++++$ UL++++$ UB+
> US+++$ UI+++$ P++>++++ L++++$ 3+ E--- N K- !W(-----) M(-) !V -po+ Y+
> t+ 5++ !j !R G' !tv b+++ D++ B--- e+ u+* h++ f? r++ n---- y?
> Recent UH+>++ UO+ UC++ U?+++ UV++ and collecting.
>
>
Re: performance mongers: since when is using CGI.pm or Apache::Registry
dishonorable?
Posted by Shevek <sh...@tirin.openworld.co.uk>.
On Fri, 31 Mar 2000, Vivek Khera wrote:
> My question to all of you who use handlers directly, how do you manage
> all your handler mappings? I've seen it done where you add a
> <Location> mapping for each handler you use, which corresponds to each
> "program" you need. This, in my experience, tends to be error prone
> and results in much cruft in your httpd.conf file.
I have a single handler which matches all files, if the file exists
($r->finfo and other tests), it returns DECLINED. Else it makes a decision
in Perl, and dispatches to the relevant handler in Perl. This makes
loading the Perl script in a server very intensive, a problem which I am
looking to solve soon.
Ta.
S.
--
Shevek
GM/CS/MU -d+ H+>++ s+: !g p2 au0 !a w+++ v-(---) C++++$ UL++++$ UB+
US+++$ UI+++$ P++>++++ L++++$ 3+ E--- N K- !W(-----) M(-) !V -po+ Y+
t+ 5++ !j !R G' !tv b+++ D++ B--- e+ u+* h++ f? r++ n---- y?
Recent UH+>++ UO+ UC++ U?+++ UV++ and collecting.
Re: performance mongers: since when is using CGI.pm or Apache::Registry dishonorable?
Posted by Perrin Harkins <pe...@primenet.com>.
On Fri, 31 Mar 2000, Vivek Khera wrote:
> My question to all of you who use handlers directly, how do you manage
> all your handler mappings? I've seen it done where you add a
> <Location> mapping for each handler you use, which corresponds to each
> "program" you need. This, in my experience, tends to be error prone
> and results in much cruft in your httpd.conf file.
Works great for me. I don't tend to have hundreds of these, because I
usually wrap groups of related functionality into one program and then use
additional URI info to determine the exact action of each request - pretty
typical multi-page CGI stuff.
I like the freedom of mapping URIs that make sense to end users to modules
in my class hierarchy that make sense to programmers. If you like the
convenience of mapping directly to files from the URI, maybe a quick hack
to treat the files as modules is in order. It could leave out the part
that wraps your code in a sub and slaps a package on it, and just do a
simple require instead (and maybe stat the file first and remove it from
%INC if it has changed, although you could just use Randal's module for
that). That would fix the things I don't like about Registry.
As for making changes without restarting, I always restart my production
servers when I change code, in order to maximize shared memory, but I can
do this because I have a cluster of servers. I could see this being a
problem if I only had one machine.
- Perrin
Re: performance mongers: since when is using CGI.pm or Apache::Registry
dishonorable?
Posted by Vivek Khera <kh...@kciLink.com>.
>>>>> "DM" == Doug MacEachern <do...@covalent.net> writes:
DM> geez. i don't recall "Apache::Registry vs. pure PerlHandler" or
DM> "Apache::Request vs. CGI.pm" ever being so harsh.
Personally, I do all my scripting in Apache::Registry. Why? Because
it is easy, and I don't always have the ability to restart the server
to update some code or modify the config to add the handler mappings.
With a bit of careful coding, you avoid any problems referred to here
before.
My question to all of you who use handlers directly, how do you manage
all your handler mappings? I've seen it done where you add a
<Location> mapping for each handler you use, which corresponds to each
"program" you need. This, in my experience, tends to be error prone
and results in much cruft in your httpd.conf file.
What other approaches are there? I think having some equivalent of
Apache::Registry which will automatically dispatch a URI to a handler,
and suck in the module if necessary would be a useful thing. (Gosh, I
hope there isn't one already that I've missed .... ;-)
As for CGI.pm being a memory pig, yep... it sure is. I used to use
CGI::Base and CGI::Request modules extensively, but they seem to have
started collecting virtual dust and nobody maintains them anymore...
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-301-545-6996
PGP & MIME spoken here http://www.kciLink.com/home/khera/
Re: performance mongers: since when is using CGI.pm or Apache::Registry dishonorable?
Posted by Ken Williams <ke...@forum.swarthmore.edu>.
marnold@novia.net (Matt Arnold) wrote:
>1. An Apache handler doesn't mean CGI.pm *ISN'T* in use
>2. Just because you don't use Apache::Registry doesn't mean you're not doing
>CGI emulation (*gasp*)
>3. Using Apache::Registry doesn't necessarily mean CGI.pm is at use
>4. Using CGI.pm is smart (aka don't reinvent CGI.pm's HTML methods)
I think somewhere you got confused about the relationship between
Apache::Registry and CGI.pm, and now you're starting to get unconfused. But
that doesn't mean that everyone else was confused the same way you were.
CGI.pm and Apache::Registry are independent. You can use one without the other
very easily. No need to associate them in this email.
>Somewhere along the line, CGI.pm became "bad, evil, and bloated". Many of
>you don't want to use CGI.pm for anything. While some of CGI.pm's
>functionality can be done more efficiently by other means (i.e.
>Apache::Request), CGI.pm's HTML methods have no such high-efficiency
>equivalents. Since laziness is one of the primary Perl virtues, isn't it
>smart to leverage the work already done in CGI.pm rather than rolling your
>own HTML methods? Can't using CGI.pm's HTML methods be considered a "good
>thing"?
Of course, a lot of people like them. I don't use them, though. HTML is a
perfectly valid language, and I don't see why I should use Perl to create HTML.
It feels like using Java to write C. If you're using one of the embedded Perl
solutions like HTML::Mason & friends, one of the goals is to let HTML be HTML
and let Perl be Perl.
>The recent thread "[ot] How to crypt the way htpasswd does..." serves as an
>example of how one can get chastised for failure to use existing code. (See
>http://forum.swarthmore.edu/epigone/modperl/nengahker for the thread.) Why
>are so many of you quick to ignore this advice? Why is this particular
>wheel one so many of you are willing to reinvent?
Well, one could make the argument that CGI.pm reinvented the wheel too - the
HTML wheel.
>Would the anti-CGI.pm crowd be more likely to use these HTML functions
>if they were in their own (presumably leaner) module unbundled from the
>"bloated, monolithic" CGI.pm?
No, I doubt it. At least, I wouldn't. There's nothing wrong with the
HTML-generation side of CGI.pm, it just does things that I don't need to do, so
I don't tend to use it.
>Perhaps this is what most of you performance mongers really mean.
It's not helpful to call people names like that. People are just trying to get
things done.
By the way, you haven't mentioned the biggest reasons that people might want to
avoid Apache::Registry. It will do a stat() on your script to see if it's
changed, and set up several things (including %ENV, which you mentioned) just
to emulate the CGI environment. There's no real reason to set these things up,
it's just for CGI compatibility. So if you don't need CGI compatibility,
doesn't it make sense that you shouldn't waste effort setting these things up?
Apache::Registry makes a lot of sense for people who need to keep their scripts
portable and CGI-compatible. Same with CGI.pm. No reason to couch things in
your black/white good/bad terms, as there is a time to use all of these very
popular tools and a time to choose other tools.
------------------- -------------------
Ken Williams Last Bastion of Euclidity
ken@forum.swarthmore.edu The Math Forum
Re: performance mongers: since when is using CGI.pm or Apache::Registry
dishonorable?
Posted by "C. Jon Larsen" <jl...@richweb.com>.
CGI.pm is a great piece of code, but its very monolithic. Lincoln/Doug's
libapreq module is probably much faster (I have never run benchmarks) than
CGI.pm, so it makes sense for those who like the Q->param type interface
(I do) for working with CGI environment variables, but don't need all the
handy html and cookie functions/methods the CGI.pm provides.
A lot of mod_perl shops have aready developed their own templating scheme,
or page object model, or are using one of Mason, ASP, embperl etc . . .
and don't have a lot of use for 85% of CGI.pm's library routines.
Again, there are c based modules now for HTTP utils and cookies as well,
which provide more speed.
The reason many prefer native Apache methods over wrapped cgi scripts is
not just speed, but coding style and maturity. Writing modules and setting
up objects requires more discipline that writing quick scripts and relying
on magic to reset your environment for the next execution run. I have
applications that now run as deep as 50,000 to 100,000 lines of code. I
don't want wrapped scripts. I want re-usable functions, objects, etc.
As developers learn to write native handlers they are starting down the
path that gets them ready for more serious action (namespace management,
using lexicals properly, etc . . . )
That being said perl is all about getting your job done before you get
fired. So an elegant registry solution should never be looked down upon
just because its a registry solution.
On Wed, 29 Mar 2000, Matt Arnold wrote:
> Many messages on this list perpetuate the notion that usage of CGI.pm and
> Apache::Registry is for beginners. Popular opinion is that you're not a
> leet mod_perl h@x0r until you wean yourself from CGI.pm and Apache::Registry
> and "graduate" to the Apache API. With this in mind, there have been many
> messages over the years making blanket statements along the lines of "CGI.pm
> is evil" and/or "Apache::Registry sux". I'm trying to identify the source
> of this disatisfaction. While it may seem that my intent is to start the
> ultimate, end-all CGI.pm/Apache::Registry flame war, please be assured that
> I am interested in ferreting out the real issues. :-)
>
> Anyway, in hope of generating some debate, I'll make some (potentially
> inflammatory) assertions:
>
> 1. An Apache handler doesn't mean CGI.pm *ISN'T* in use
>
> The "Apache::Registry sux" crowd claims I should forgo Apache::Registry and
> write handlers instead. Okay, here's my handler:
>
> # in httpd.conf
> <Location /foo>
> SetHandler perl-script
> PerlHandler Apache::Foo
> </Location>
>
> package Apache::Foo;
> use strict;
> use CGI ();
> sub handler {
> my $q = CGI->new;
> print $q->header;
> print "Hello World\n";
> 200;
> }
> 1;
>
> Satisfied? No Apache::Registry in use here. Am I a l33t h@x0r now? No?
> Why not? Oh, so when the zealots say, "Apache::Registry sux, write handlers
> instead" they really mean I should be using the Apache API instead of
> CGI.pm. I see.
>
> I have another beef with the "CGI emulation sux, avoid Apache::Registry"
> crowd. And that is:
>
> 2. Just because you don't use Apache::Registry doesn't mean you're not doing
> CGI emulation (*gasp*)
>
> What exactly is this "evil, bloated, slow CGI emulation" that everyone's
> trying to avoid? Is it the overheard of setting up all the environment
> variables? Well, gee whiz, regular handlers do this too unless you tell
> them not to. Try the following exercise:
>
> <Location /env>
> #PerlSetupEnv Off # try first without; then try with PerlSetupEnv Off
> SetHandler perl-script
> PerlHandler Apache::Env
> </Location>
>
> package Apache::Env;
> use strict;
> use Data::Dumper qw(Dumper);
> sub handler {
> my $r = shift;
> $r->content_type('text/plain');
> $r->send_http_header;
> $r->print(Dumper(\%ENV));
> 200;
> }
> 1;
>
> So let's not be so quick to curse Apache::Registry for it's "slow" CGI
> emulation. Your "fast" handlers are probably doing the same thing
> unbeknownst to you.
>
> Another assertion:
>
> 3. Using Apache::Registry doesn't necessarily mean CGI.pm is at use
>
> It seems the "Apache::Registry sux" crowd dislikes Apache::Registry because
> it implies that CGI.pm is in use. Perhaps their real gripe is one should
> use the Apache API instead of CGI.pm's methods. So how would they feel
> about this:
>
> # in httpd.conf
> <Location /bar>
> PerlSetupEnv Off # we don't need no stinking ENV
> SetHandler perl-script
> PerlHandler Apache::Registry # or Apache::RegistryNG->handler
> Options +ExecCGI
> </Location>
>
> #!/usr/local/bin/perl -w
> use strict;
> my $r = Apache->request;
> $r->content_type("text/html");
> $r->send_http_header;
> $r->print("Hi There!");
>
> Does this count? Am I a l33t h@x0r because I used the Apache API? Or am I
> still a lamer for using Apache::Registry?
>
> I can hear the hordes out there crying, "Why use Apache::Registry if you're
> not using CGI.pm?" Well, perhaps I have a couple hundred scripts and don't
> want to maintain several hundred <Location> directives in httpd.conf. Maybe
> I like Apache::Registry's convenient way of grabbing my script, wrapping it
> into a handler on-the-fly, and serving it up. Isn't this one of the handier
> features of Apache::Registry? (Note: I'd like to hear of alternatives to
> Apache::Registry[BB|NG] for doing this.)
>
> So maybe Apache::Registry isn't pure evil after all. So perhaps the zealots
> clarify their mantra to be simply "CGI.pm sux". That leads us to the next
> assertion.
>
> 4. Using CGI.pm is smart (aka don't reinvent CGI.pm's HTML methods)
>
> Somewhere along the line, CGI.pm became "bad, evil, and bloated". Many of
> you don't want to use CGI.pm for anything. While some of CGI.pm's
> functionality can be done more efficiently by other means (i.e.
> Apache::Request), CGI.pm's HTML methods have no such high-efficiency
> equivalents. Since laziness is one of the primary Perl virtues, isn't it
> smart to leverage the work already done in CGI.pm rather than rolling your
> own HTML methods? Can't using CGI.pm's HTML methods be considered a "good
> thing"?
>
> The recent thread "[ot] How to crypt the way htpasswd does..." serves as an
> example of how one can get chastised for failure to use existing code. (See
> http://forum.swarthmore.edu/epigone/modperl/nengahker for the thread.) Why
> are so many of you quick to ignore this advice? Why is this particular
> wheel one so many of you are willing to reinvent? Would the anti-CGI.pm
> crowd be more likely to use these HTML functions if they were in their own
> (presumably leaner) module unbundled from the "bloated, monolithic" CGI.pm?
>
> With all this in mind, we can finally arrive at...
>
> 5. Don't use CGI.pm for what can be done elsewhere, faster
>
> Perhaps this is what most of you performance mongers really mean. Don't use
> CGI.pm to do stuff the API can do -- use the Apache API or Apache::Request
> instead. And be sure to set "PerlSetupEnv Off" unless you need it. This
> seems like good advice. See how easy it is to give out good advice without
> any disparaging comments against CGI.pm or Apache::Registry. :-)
>
> So I'm hoping you'll agree that it's still possible to have a
> highly-efficient system and be a leet mod_perl h@x0r while still using
> CGI.pm and Apache::Registry. Leveraging CGI.pm's HTML functions is smarter
> than reinventing your own. And the use of Apache::Registry doesn't
> necessarily mean CGI.pm or "CGI emulation" are in use.
>
> Thanks in advance for your flames, er... replies.
>
> Matt
>
> P.S. The terms l33t h@x0r, zealot, performance monger, and code wanker are
> intended to be complimentary -- not inflammatory. (Well, okay, code wanker
> is intended to be inflammatory, but I never used that term.)
>
> P.P.S. I should have some benchmarks soon showing CGI.pm vs.
> Apache::Request, handler vs. Apache::Registry vs. Apache::RegistryBB,
> PerlSetupEnv Off vs. On, etc.
>
>
>
>
Re: performance mongers: since when is using CGI.pm or Apache::Registry
dishonorable?
Posted by Doug MacEachern <do...@covalent.net>.
geez. i don't recall "Apache::Registry vs. pure PerlHandler" or
"Apache::Request vs. CGI.pm" ever being so harsh.
but they have been compared, for good reason.
Apache::Registry maps a request to a file and generates a subroutine to
run the code contained in that file. if you use a 'PerlHandler
My::handler' instead of Apache::Registry, you have a direct mapping from
request to subroutine, without the steps inbetween. these steps include:
stat the $r->filename
check that it exists and is executable
generate a Perl package name based on $r->uri
chdir basename $r->filename
compare last modified time
if modified or not compiled, compile the subroutine
chdir $old_cwd
if you cut out those steps, you cut out some overhead, plain and simple.
do you NEED to cut out that overhead? i don't know, your requirements
determine that.
as for CGI.pm vs. Apache::Request.
last i checked 'use CGI qw(-compile => ':all') adds 1Mb size to the
server. CGI.pm pulls lots of stunts under the covers to provide both a
method and function interface, etc. Apache::Request is a very thin xs
layer on top of a C library and only adds a few k size to the server.
this C code is much faster and lighter than the Perl equivalent used in
CGI.pm or similar (e.g. CGI_Lite). again, this difference might not
matter much to you, depending on your requirements.