Re: Why people not using mod_perl

[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