On Wed, 24 Nov 1999, Parand T. Darugar fingerwiggled:
> Dear Star,
>
> > In the document http://www.binevolve.com/velocigen/competition.vet#mod_perl
> > you propose a number of things about mod_perl that are misleading at best, and
> > out-right wrong at worst.
>
> This competitive analysis was looked over by several mod_perl
> and web development gurus. Vivek Khera, author of the mod_perl
> tuning document, gave his blessing to this analysis. It's very
> difficult to write a competitive analysis without upsetting
> proponents of the other product, but we feel our analysis is
> correct and honest.
Have a look @ Vivek Khera's own words:
http://www.bitmechanic.com/mail-archives/modperl/Jul1999/0701.html
His blessing?
> As a company, we've very often promoted mod_perl. We feel mod_perl
> is a very good solution. Some people look for professional
> support and want a company behing the product they are using.
> Or, they are using a server other than Apache, or are looking
> for easier installation, etc. This is where VelociGen comes in.
> We even have some customers using mod_perl that rely on us for
> support.
I fully understand the concept of "vendor support"... it's the misleading
comparison that I dont like.
>
> > Why must you leave out such things as shared libperl.so and other basic tunning
> > to make your product look better?
>
> Ask anyone who runs a fairly busy mod_perl site and they'll
> tell you that each apache daemon is at least 4 to 6 megs,
> often much bigger. Much of this is the cached scripts in memory.
> When you have 50-60 daemons you start running into problems.
> The mod_perl tuning guide (http://perl.apache.org/tuning/)
> discusses these situations in some detail.
Here's a snip from an email that I just receved from one of your
co-workers, Alex Shah <[EMAIL PROTECTED]> in response to this same
email:
---begin quote
Why the comparison with mod_perl? This was part of the agreement we
made with Sun in order to bundle our product with their web server. It
was a strategic decision which step on mod_perl toes. Sun needed us to
come up with a white paper to show how the new iPlanet web server was
superior to the free Apache solution.
---end quote
> > I understand that you guys even use core mod_perl code in your product,
> > and yet you have to resort to FUD aginst mod_perl to sell it.
>
> VelociGen was written completely independently of mod_perl -
> in fact mod_perl wasn't really around when we start writing the
> code for the Netscape and IIS versions of VelociGen. Our Apache
> port came out quite a bit later, and we didn't use any mod_perl
> code for that. Our architecture is quite a bit different, so
> not a lot of the code is applicable. We do use Apache::DBI, and
> possibly one or two other Perl modules, which could be classified
> as parts of mod_perl, but to say VelociGen uses core mod_perl code
> is entirely inaccurate.
My bad... sorry, I should have checked my sources.
http://perl.apache.org/products.html
It says "Products based on the mod_perl architecture.."
> As I've said many times before, I feel the real competition
> is from the Java camp. We don't have an interest in fragmenting
> the Perl market - instead, we'd like to grab market share from
> these other tools. We just completed some testing that showed our
> Perl based solution to be more than twice as fast Java Server Pages.
Even if you did fragment the perl camp, that would just lend credance to
your product, ya know? Again it is the *marketing* and the mud slinging
aginst mod_perl that I don't dig and the only reason I wrote the email in
the first place. No Holy Wars, just the facts...
> Best,
>
> Parand Tony Darugar [EMAIL PROTECTED]
> 858-622-1164 High Performance Perl Server Pages
> 858-481-7438 fax Load Testing and Performance Tuning
> http://www.binaryEvolution.com/ XML Server Pages
>
>
regards,
--
<*>
