On Fri, 23 Jun 2000, Stas Bekman wrote:
> 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.
I thought it was quite a good article actually, and fairly FUD free.
> This posts tries to fix incorrect details mentioned in the article.
>
> 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.
Perhaps this is just a language barrier. Many of us consider Apache to be
a web platform. The OS is almost immaterial: Apache is your platform
(which hopefully becomes even more true with Apache 2.0, and mod_perl 2).
> -------------
>
> "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?
Yes, of course you do. Beyond the simple "perl Makefile.PL, make, make
install" you need to learn how to configure Apache, and read all the stuff
in the guide. Not always a bad thing, IMHO. Just that the article is
saying that VG does this out of the box.
> -------------
>
> "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
I still find the mod_perl INSTALL docs don't get to this point soon
enough. I guess I should submit a patch :)
You have to _know_ to read INSTALL.apaci, not INSTALL, and even then
INSTALL.apaci doesn't get to the information soon enough. I kind of feel
like you're sweeping this argument under the carpet, when I'm all too well
aware that its a serious issue (we're shipping a commercial product with
Apache + mod_perl soon, and installation is a PITA to say the least).
> -------------
>
> "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.
PHB's like the output from Velometer, that's all. Its a nice graph that
they can point to and print out and show their bosses. Not much of an
argument though since you can run it yourself on mod_perl if you download
it :)
> --------------
>
> "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?
WT has space limitations. I'm willing to bet that the original submission
included all three examples. They should be able to put that right on
their web site, but obviously that's beyond their abilities. Why do you
think Randal publishes all his WT articles on his own site? :-)
> --------------
>
> "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.
Yes, but it takes some experience with mod_perl to get to the point of
having lots of shared memory - knowing where the guide is and reading the
whole thing is a good start of course, but not many people do that before
getting into mod_perl usage (as is evident by some of the traffic on this
list). And then you get into the whole dirty pages stuff and you've lost
80% of the WT readers right there!
> --------------
>
> "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.
Well I don't see this as FUD either. When you move to a new architecture
it should be an absolute prerequisite to spend a fair bit of time testing
and maybe debugging.
> =================================
>
> 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)
I got the feeling that it was written from the point of view of someone
trying out 2 new technologies, not the other way around. YMMV.
The point is: mod_perl has its weaknesses. Installation is one. Memory
usage is another. The tie to Apache might be considered another (although
I'm of the opinion that other web servers should be implementing ApacheAPI
in their servers - I'm trying to persuade my boss to add it to WebSite
Pro, for starters). mod_perl is great for advanced web site
builders. Velocigen is great for drop-in performance enhancement with lots
of stuff PHB's like. Use what works for you.
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
