here's a missive fired off by the site admin after he "benchmarked" two
scripts, one written in php and one written in perl/cgi
>
> First of all.
>
> Dude. you're out of your mind. Im serious.
>
> The WHOLE point about why PHP is faster than Perl is because the
> interpreter is compiled into Apache.
he's not running a perl interpreter compiled into Apache.
> Also. the fact that your script caused MySQL to use up all of it's
> connections has -nothing- to do with PHP being compiled into Apache.
I find this terribly difficult to believe, but I'm willing to post my
cgi for review both here and in the DBI list
> We simply do -not- have the hardware to run mod_perl. With our level of
> traffic, we would need a load balanced cluster to handle this.
>
> We skewed nothing. We ran the same apache bench command for both
> scripts. Same number of concurrent requests, same number of times. Do not
> confuse ApacheBench with some useless little tool. This is for serious
> server benchmarking. The fact that we're using gemini table types and
> your database tables are indexed just further shows the limitations of
> Perl.
>
> You simply don't get it. PHP, in all of it's forms, blows perl out of the
> water. I've been writing both since early 1993, and in every case, in
> every instance, PHP crushes perl for speed. That's -why- it was created
> (build in interpreter). That's -why- Zend released the PHP4 engine.
> That's -why- we're running Zend Optimizer. If perl was the shit for doing
> CGI, why would anyone even bother creating things like PHP? That's like
> the Chewbacca website. It makes no sense.
>
> mod_perl is a resource pig. I refuse to install something on a server that
> will make life miserable for everyone else. I've seen GHz machines hauled
> off of their foundations because of mod_perl, while the same server
> running PHP code has no problems whatsoever.
I responded with certain information along these lines:
-=-
> > If you use CGI.pm in many of your mod_perl scripts, you may want to preload
> > CGI.pm and its methods at server startup time. To do this,
> > add the following line to httpd.conf:
> >
> > PerlScript /home/httpd/conf/startup.pl
> >
> > Create the file /home/httpd/conf/startup.pl and put in it all the modules
> > you
> > want to load. Include CGI.pm among them and call its
> > compile() method to precompile its autoloaded methods.
> >
> > #!/usr/local/bin/perl
> >
> > use CGI ();
> > CGI->compile(':all');
> >
> > Change the path to the startup script according to your preferences.
>
> if you're gonna benchmark at least do it right.
>
> don't flap statistics at my face when you've got sandbags tied around the
> feet of all my peasants, and shot each one in the foot as well, please.
>
> Also, Yoda's script is not performing (and from what I can see, can not
> perform ) the same query mine was (again skewing the 'benchmark')
>
> searching his script for 'c' does not return even the same list of maps mine
> does. I feel that a certain degree of *accuracy* is also important in a
> benchmark.
>
> I've also gone to the trouble of doing things such as this:
>
> my( $type, $id, $filename, $title, $size, $reviewfile, $rating, $rated,
> $oldtype );
> $sth->bind_columns(\$type, \$id, \$filename, \$title, \$size,
> \$reviewfile, \$rating);
>
> which binds the results of each return into the same variable reference to
> save on memory and processing while looping through the fetch, instead of
> thrashing the symbol table.
>
> and other things like this
>
> # die with status error if necessary if cgi itself got an error
> if (!param() && cgi_error()) {
> print header(-status=>cgi_error());
> goto FINISH;# don't call ex
