You are viewing a plain text version of this content. The canonical link for it is here.
Posted to advocacy@perl.apache.org by mo...@att.net on 2004/11/30 23:38:11 UTC
Why people not using mod_perl
Hi, there:
just subscribed to this advocacy list.
First, sorry to Frank. I was replying his email in the user list
but was wrongly put his address as the subject. :-(
Please let me share some of my experiences in using mod_perl.
There are four factors when choose a particular language:
1) easy to program
cgi is very easy to use, and php is easy. mod_perl and
java servlet are hard.
2) speed
mod_perl is fast but php is fast too (if not faster),
and so is Java servlet.
3) capacity/scalable
mod_perl is very scalable --- I mean, one can properly
config a single server to handle dynamic content for
200K daily unique IPs. PHP may end up with just 100K
and servlet ends up at around 50K.
However, even the old CGI can handle 20K unique IPs
with a new CPU. Since most sites won't
need to go above 20K IPs, this advantage is not that
attractive in practice.
And what is worse is that the current existing mod_perl
toolkits seem not scalable when compared to PHP. I knew
2 cases where people gave up the mod_perl toolkit
and turned to PHP.
4) easy to manage, work as team
both mod_perl and servlet are good to be written in OO
(and the so-called MVC). PHP is bad.
But again, majority webmasters don't need OO or MVC.
5) learning curve, friendly environment, existing applications etc.
PHP is the best, then serverlet; mod_perl is the worst.
Based on the above situation, we see that the potential mod_perl
users are those who are using or will choose Java servlet,
and advanced PHP users who need the projects to be in OO and MVC.
To advocate mod_perl, the priorities rank as:
1) focus on mod_perl's ability of OO / MVC
2) scalability (only the original mod_perl, not toolkits)
3) and speed
4) avoid toolkits but diretly go to XHTML.
POD MERL
---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org
Re: Why people not using mod_perl
Posted by Eric <ef...@kwinternet.com>.
At 02:38 PM 11/30/2004, you wrote:
>Hi, there:
>
>just subscribed to this advocacy list.
>
>First, sorry to Frank. I was replying his email in the user list
>but was wrongly put his address as the subject. :-(
>
>Please let me share some of my experiences in using mod_perl.
>
>There are four factors when choose a particular language:
>
>1) easy to program
>
>cgi is very easy to use, and php is easy. mod_perl and
>java servlet are hard.
For most people I have worked with/for, this is number one. The rest can
take a hike. Anything else is often considered a bias or religion. THAT is
why PHP is so big, quick and dirty rules. And remember, it is about this
perception, not the reality and it is not considering the consequences.
PHP is loaded with special functions for things that are just not that fing
hard to do, but they make things easier, at least that is the opinion. I
myself HATE big APIs that is why I have avoided Java to a large degree, and
PHP is just insane, esp with not even being able to have consistent names
for the functions that keep getting piled on. It is also getting a lot
easier to do MVC with PHP. For example a guy ported CGI::Application to PHP
and that combined with Smarty template is pretty close to what you would be
doing with Perl and does avoid at least a lot of the mess I see with a lot
of PHP collections.
>2) speed
>
>mod_perl is fast but php is fast too (if not faster),
>and so is Java servlet.
I did some benchmarks on our servers, without tweaking/Zend PHP can dog it
just as bad as CGI, assuming it is not running as a CGI which is still not
at all uncommon. It actually surprised me. But like you were saying what it
does is enough for what we need on those servers. I was comparing a nothing
PHP script to a mod_perl Registry big ass app too. Yes, just our one case..
>3) capacity/scalable
>
>mod_perl is very scalable --- I mean, one can properly
>config a single server to handle dynamic content for
>200K daily unique IPs. PHP may end up with just 100K
>and servlet ends up at around 50K.
>
>However, even the old CGI can handle 20K unique IPs
>with a new CPU. Since most sites won't
>need to go above 20K IPs, this advantage is not that
>attractive in practice.
>
>And what is worse is that the current existing mod_perl
>toolkits seem not scalable when compared to PHP. I knew
>2 cases where people gave up the mod_perl toolkit
>and turned to PHP.
>
>4) easy to manage, work as team
>
>both mod_perl and servlet are good to be written in OO
>(and the so-called MVC). PHP is bad.
>
>But again, majority webmasters don't need OO or MVC.
>
>5) learning curve, friendly environment, existing applications etc.
>
>PHP is the best, then serverlet; mod_perl is the worst.
This part I don't get. When I ask a semi advanced question on a PHP list I
get a lot of just stupid responses or dead air. Biggest in this case is
certainly not best. On the mod_perl list I pretty much end up feeling
stupid for asking the question, because the answer comes so quickly and is
so simple :)
>Based on the above situation, we see that the potential mod_perl
>users are those who are using or will choose Java servlet,
>and advanced PHP users who need the projects to be in OO and MVC.
>
>To advocate mod_perl, the priorities rank as:
>1) focus on mod_perl's ability of OO / MVC
>2) scalability (only the original mod_perl, not toolkits)
>3) and speed
>4) avoid toolkits but diretly go to XHTML.
>
>
>POD MERL
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
>For additional commands, e-mail: advocacy-help@perl.apache.org
Lead Programmer
D.M. Contact Management
250.383.8267 ext 229
---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org
Re: Why people not using mod_perl
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2004-11-30 at 22:38 +0000, modperl@att.net wrote:
> 4) avoid toolkits but diretly go to XHTML.
What are these toolkits you're talking about? Things like Mason,
Apache::ASP, and Template Toolkit? I wouldn't want to tell people not
to use templates. These things provide ease of use, which really
matters to some.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org
Re: Why people not using mod_perl
Posted by Frank Wiles <fr...@wiles.org>.
On Tue, 30 Nov 2004 22:38:11 +0000
modperl@att.net wrote:
> First, sorry to Frank. I was replying his email in the user list
> but was wrongly put his address as the subject. :-(
No worries.
> 1) easy to program
>
> cgi is very easy to use, and php is easy. mod_perl and
> java servlet are hard.
A Perl CGI can easily be "mod_perl enhanced" by a few simple
Apache configuration changes. I don't see what is so hard about
that. I also think mod_perl is much easier for a Perl programmer
to migrate toward than a Perl programmer taking up PHP or Java.
The learning curve is bitten off in more easily digestable chunks.
> 3) capacity/scalable
>
> mod_perl is very scalable --- I mean, one can properly
> config a single server to handle dynamic content for
> 200K daily unique IPs. PHP may end up with just 100K
> and servlet ends up at around 50K.
>
> However, even the old CGI can handle 20K unique IPs
> with a new CPU. Since most sites won't
> need to go above 20K IPs, this advantage is not that
> attractive in practice.
>
> And what is worse is that the current existing mod_perl
> toolkits seem not scalable when compared to PHP. I knew
> 2 cases where people gave up the mod_perl toolkit
> and turned to PHP.
I'm not sure which toolkit they gave up on, but I've found that
a lot of people give up too easily on these things. Often their
problem can be solved by a few quick config changes and tweaks if
they would just google for it or ask on a mailing list.
Also, like you said most sites will never run into these problems
and some of us aren't running traditional websites with mod_perl, but
using it for web applications that aren't hit at the same rates as
websites.
> 4) easy to manage, work as team
>
> both mod_perl and servlet are good to be written in OO
> (and the so-called MVC). PHP is bad.
>
> But again, majority webmasters don't need OO or MVC.
I think this is more of a function of how the programmers work than
the language or programming methodology. History has shown you can
build large projects with hundreds of developers in a non-OO style
and with no revision control ( read linux kernel until a few years
ago ).
> 5) learning curve, friendly environment, existing applications etc.
>
> PHP is the best, then serverlet; mod_perl is the worst.
Learning curve really depends on where you are coming from. If you're
talking about a webmaster that only knows Dreamweaver, XHTML, and a
smattering of CSS, learning Java servelets and mod_perl are probably
on equal footing.
However, if you already know a smattering of Perl, which most
webmasters or admins already do, then learning mod_perl is just
another small step. You already know the language, you just have to
learn the Apache API.
> Based on the above situation, we see that the potential mod_perl
> users are those who are using or will choose Java servlet,
> and advanced PHP users who need the projects to be in OO and MVC.
>
> To advocate mod_perl, the priorities rank as:
> 1) focus on mod_perl's ability of OO / MVC
> 2) scalability (only the original mod_perl, not toolkits)
> 3) and speed
> 4) avoid toolkits but diretly go to XHTML.
I disagree with this a bit as the toolkits can scale, they just
sometimes need to be tuned for a site. For example, I know there are
large sites out that using Template Toolkit and Mason without any
trouble. I'm sure they have had to tweak their configs, but if you're
running a large scale website without doing some tweaking you are
spending WAY too much money on hardware! :)
---------------------------------
Frank Wiles <fr...@wiles.org>
http://www.wiles.org
---------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org