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.

Reply via email to