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.
