You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Stas Bekman <st...@stason.org> on 2000/06/23 10:29:38 UTC
[advocacy] FUD spreading by velocigen fan
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:stas@stason.org http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: [advocacy] FUD spreading by velocigen fan
Posted by Stas Bekman <st...@stason.org>.
On Fri, 23 Jun 2000, Matt Sergeant wrote:
> 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.
I didn't said it was bad, I said that mod_perl wasn't shown in a quite
right way.
> > 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).
Hmm, this makes things different. However I disagree with you that it has
anything to do with a language barrier. I read lots of news/info about
all the web stuff and I don't think I can tell that I read about Apache
being a platform. But I'll not argue about that, since I could read all
the wrong stuff in all the wrong places :) So let's put this item aside.
> > -------------
> >
> > "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.
You are right. May be I've jumped too high here, when looking from my
tower :)
> > -------------
> >
> > "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 :)
What stops you to?
> 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).
well you have
Installing mod_perl in 10 Minutes and 10 Command Lines
http://perl.apache.org/guide/install.html#Installing_mod_perl_in_10_Minute
The one I've extended in the yesterday article:
http://apachetoday.com/news_story.php3?ltsn=2000-06-23-002-01-NW-LF-SW
May be we should add a new file: INSTALL.NOW or INSTALL.FAST?
> > "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 :)
Matt, my problem with this article was in fact, that it compares the two
technologies, even if it claims to review only velocigen. mod_perl was
shown one sided. So velocigen has a java applet, but mod_perl has many
other things that weren't mentioned.
I believe the article (which is probably quite good at reviewing
velocigen, I cannot judge it since I'm not familiar with it) would be much
fair if it won't touch mod_perl at all. Remember that the URL of the
article was posted to the list, saying that the article compares mod_perl
with velocigen. I prefere having two fair articles about two technologies
instead of the article that we are talking about.
> > "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? :-)
Well, in that case the article had to be adapted to remove the information
that cannot be verified. And in any case, 2k script leads constraint? That
doesn't sound true to me, we are living in 2000!
As for Randals articles, I guess we should ask Randal, before trying to
guess the true reasoning :)
> > "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!
True. But you see, the article doesn't mention that. But I see an easy
solution for this obvious pitfall, here is my continuation of the last
quote:
"... So for memory utilization, VelociGen is the winner, compared to out
of box mod_perl. If you invest your time into learning more about
mod_perl, mod_perl definitely wins the memory usage game.
> > "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.
No argueing again. My woe was about not mentioning these two modules.
> > 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.
I wish your last paragraph would conclude the article. I won't say a word
if it did.
In my opinion all technologies are cool, and the more emerge the better
for us. The only thing that should be ensured that whenever you try to
compare two and more of them, *all* or at least as many as possible
factors will be said. Since if the comparison fails to do that, the
reader get a one sided opinion about technologies, which is bad for him
and for him only. I'm not worried about my self, but the users, who might
miss the exact thing they were looking for, misleaded by incomplete (not
even wrong) information.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: [advocacy] FUD spreading by velocigen fan
Posted by Matt Sergeant <ma...@sergeant.org>.
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