[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl
Subject:    Re: getting to know more about mod_perl
From:       Jonathan Vanasco <modperl-list () 2xlp ! com>
Date:       2006-08-29 22:56:46
Message-ID: E4EEBFFB-F28E-448D-BDCA-BF64D833AF1F () 2xlp ! com
[Download RAW message or body]


On Aug 29, 2006, at 3:08 PM, Adriano Ferreira wrote:

> I meant cost with respect to the machine resources: mainly, memory and
> processor time. Thanks a lot for the various references that I am
> going to absorb.

mod_perl consumes more memory than php- php compiles into a smaller  
footprint, but it is a bit faster.

mod_perl caches the compiled perl code into memory.  php requires a  
third party cache to do that ( eaccelerator or one of the other  
opcode optimizers that also do memory caching ).

mod_perl requires apache- its about extending /configuring apache  
with perl, and interfacing with the entire server and request  
cycle.    in essence, mod_perl gives you a fully scriptable web server.

php is just a content-generating scripting language.  you can run it  
via mod_php or fastcgi, or even with a non-apache  server (lighttpd,  
nginx, thtppd ).  it doesn't hook into any server like mod-perl.

the drawback to that, is that you're locked into Apache if you use   
mod_perl... and you have more server options if you use PHP.  That's  
only for the dynamic content though- with a smart reverse proxy or  
load balancer, you can specify which servers serve what.

> About security (as an example), I remember to have read somewhere that
> Apache::DBI can be dangerous because of the sharing of the DB
> connections and the openness of Perl - a malevolent user could try
> (and succeed) to access connections of other applications as they are
> running in the same interpreter. But, there are no such issues in PHP
> as well?

possibly, but its a moot point.  (btw, it would generally be  
applications running in the same apache child, as db connections are  
best made post-fork )
	because of design of mod_perl (ie intensive memory use ) people do  
not normally run mod_perl on a shared server.   mp usually sits on  
its own box, and is tweaked for speed / performance -- getting the  
most out of your server.
	php is also geared towards multi-user setups (ie: shared hosting).

if you want to talk about security though, php has a long history of  
bad security exploits.  they've gotten a lot better, but for a few  
years, you'd have to upgrade php every other  week.

in practice , i've seen that people make 'applications' on mod_perl-  
large systems that serve a single purpose - and 'projects' in php.   
i'm not saying that you can't make a large site in php or a small  
site in mod_perl... i'm just saying that its best to choose the right  
tool for the job.  everyone i know who does anything semi-large in  
php, goes crazy tweaking 3rd party optimizers and accelerators

in terms of programmers, there's a plethora of awful-novice php  
programmers out there, that will work for next to nothing.  probably  
100x more than mod_perl programmers.

but you get what you pay for.

a  well versed php or mod_perl expert are both going to demand  
similar wages, and be 100% worth their cost.

look at what you want to build now, and where you want it to go  
tomorrow-- and choose the right tool for that job.  it might be  
mod_perl, it might be php, it might be something else.  but  
popularity and marketing are hands down the  two WORST factors to go  
by though.

[prev in list] [next in list] [prev in thread] [next in thread]