In the article "Up to Speed with VelociGen" located
http://www.webtechniques.com/archives/2000/05/infrrevu/ Brian Wilson
tries to compare Velocigen with mod_perl, unfortunately gives lots of
FUD for mod_perl instead of having a true comparison.
For those who don't know FUD is an abbreviation standing for "Fear,
Uncertainty, Doubt", a technology developed by IBM and standardized by MS.
For more info see: "WHAT IS FUD?"
http://www.geocities.com/SiliconValley/Hills/9267/fuddef.html
This posts tries to fix incorrect details mentioned in the article.
-------------
There is a link to Velocigen site, but not the mod_perl site.
-------------
"The most critical distinction between VelociGen and mod_perl is that
VelociGen is available for a wider variety of platforms. I tested
VelociGen with Apache on a Linux system, but it's also available for
several flavors of UNIX, Win32 platforms, and a variety of servers
including the Netscape server and Microsoft IIS. Mod_perl runs only
with Apache."
This sounds like a broken sentence to me:
"VelociGen is available for a wider variety of platforms...
... Mod_perl runs only with Apache."
Pardon me, but what "platforms" "platforms" has to do with specific
applications? mod_perl is available for all platforms Apache
available for. The above quote should say:
The most critical distinction between VelociGen and mod_perl is that
VelociGen is available for a variety of web servers, while mod_perl
^^^^^^^^^^^
is available only for Apache.
-------------
"There are other features in VelociGen that aren't built into mod_perl
but can be implemented other ways. These include the caching of
dynamically generated pages and running the Perl engine on a separate
server. But doing so requires more knowledge and work."
Huh? Do I miss something? You need more knowledge and work to cache
pages? and to run a separate mod_perl server?
-------------
"With regard to installation, VelociGen wins hands down; it's a
ten-minute installation. If you have to install mod_perl from source
code, installation is far more complex than I can get into
here. However, it's not bad if you can use a binary distribution of
mod_perl like the one that comes with RedHat Linux."
Huh? Oh my, look at how complicated it is:
% cd /usr/src
% lwp-download http://www.apache.org/dist/apache_1.3.12.tar.gz
% lwp-download http://perl.apache.org/dist/mod_perl-1.24.tar.gz
% tar -zvxf apache_1.3.12.tar.gz
% tar -zvxf mod_perl-1.24.tar.gz
% cd mod_perl-1.24
% perl Makefile.PL APACHE_SRC=../apache_1.3.12/src \
DO_HTTPD=1 USE_APACI=1 PERL_MARK_WHERE=1 EVERYTHING=1
% make && make test && make install
% cd ../apache_1.3.12
% make install
-------------
"Binary Evolution provides a nifty Java program called Velometer that
measures server response times with simulated users. It's available as
a free download from their Web site. I used it to test a trivial Perl
script, which simply puts the current time into a Web page."
And what if I don't have Java installed? Apache comes with ApacheBench
utility to do the same. Worth mentioned that I guess. Having a Java
program has no added value for me.
--------------
"Keep in mind that what we're really timing here is the load time for a
very small program; the actual execution time should be close on all
three examples. There are lots of other factors affecting timing on a
real system under load but VelociGen appears to be the fastest, with
mod_perl a close second."
Three examples? Huh? There is only one example showed! How can a user
judge and verify the above statement without seeing the code that was
used for the comparison?
--------------
"As you can see in Table 1, adding mod_perl to Apache causes it to use
a lot more memory. VelociGen can be loaded into Apache the same way to
give a performance boost, or it can be loaded as a separate engine via
the Apache fastcgi module.
Apparently by default, six fastcgi daemons are started. The memory
usage of Apache combined with VelociGen is still half that of Apache
and mod_perl.
With lots of Web page requests coming in, the number of httpd
processes running increases to handle the load. So with 30 copies of
httpd running, the Apache/mod_perl version uses around 230MB of
memory, whereas the VelociGen version is down around 88MB. So for
memory utilization, VelociGen is the winner."
If you look at the table, it shows no shared memory info. And I'm sure
that the testing didn't preload the code that was used. Therefore all
this info is incorrect.
--------------
"To convert existing CGI scripts to run under either VelociGen or
mod_perl, you should expect to spend a fair bit of time testing and
debugging, but the ensuing performance gains make it worth the
investment."
Huh? In most cases the scripts are running out of box under
Apache::Registry or in the worst case under Apache::PerlRun.
=================================
Conclusion: Apparently the article is written by a person who aren't very
experienced with mod_perl and still chooses to claim that he is (derived
from the fact that Brian didn't say otherwise), which leads to the FUD,
while I beleive as a not intended one. If I'd write a comparison article
I'd submit it to the both camps for a review to collect the true fact. I
admit I've no experience with velocigen technology, and based on my notes
you will see that all I'm trying to do is to fix things that said
incorrectly about mod_perl, I'm not trying to tell who's better.
I've cc'ed Brian, the author of this article in hope that the article
will be corrected based on my notes or a rebuttal to be written.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
