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:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
