You're comparing Apples to Rocks with php & mod_perl ( rocks was the
first non-fruit thing I could think of )
php has 3 main flavors - mod_php , php-cgi , php-cli
lets just look at mod_php and php-cgi
if you run perl and php through a fastcgi proxy , you're going to
get similar performance from an architecture standpoint. each
language will be a bit faster or slower depending on its strengh or
weakness in whatever you test, but the overall design of the systems
will be the same, and you won't see much of a difference.
mod_php and mod_perl sound kind of similar..
mod_php is sticking a php interpreter in apache , and using that to
process files
mod_perl is sticking a perl interpreter in apache , and using that
to process files ( it can script apache + integrate with hooks too )
but they behave a little differently because of the way they have
very different approaches in the way they handle memory - shared
memory, loading libraries, copy on write, etc
they also have slightly different architectures
most people use mod_perl in dedicated environments -- it achieves its
speed performance by compiling & caching code -- which eats up
memory. because code is handled with the package namespaces, people
generally don't run it in shared environments, as you provide
security from people overwriting namespaces can only happen by
consuming more memory to create isolated namespaces in the children.
some people here may disagree with me and chime in...
but i strongly advise not depending on mod_perl if you don't have
'root' access for apache. you're going to create a lot of headaches
for yourself, and you're only going to be able to experience a
limited subset of features & optimizations that are offered. as a
bad analogy, your experience with mod_perl is going to be like
driving a sportscar around in a crowded parkinglot - you're stuck
with a small speedlimit and you can't leave the lot and really see
whats under the hood.
if i were in your situation, i'd do the following:
1, try to get root access , so you can run/write handlers or
registry stuff that won't depend on reload
2, look into your options with running perl via fast-cgi
3, stick to php. drop apache, switch to nginx and run php via fast-
cgi , utilizing the APC cache ( or the eaccelerator one if its
working again )
a while back I benched a simple app in php & perl, using the phptal &
petal libraries:
20 r/s - mod_php / Apache
150 r/s/ - php-cgi / apc / nginx
200 r/s - mod_perl
the huge speed differences between nginx and mod_php was due to:
a- nginx is faster/more lightweight, tied up less resources than apache
b- apc cached the phptal templates & engines way better than the
standard php stat or whatever it does. i didn't bench rps under
apache using apc and not, but the generation time went from .7
seconds to .09 per page. it was a HUGE difference on that alone.
c- mp likely edged out php because perl is just kickass with text-
processing, which is primarily what i benched.
that said, if you don't like perl - don't use it. there are lots of
ways to improve your php performance.
i still use php -- we have a lot of micro-sites and templates that we
don't want to cache. running that stuff in php lets us easily
specify how much memory we want to limit that too , and keep it
isolated from our main perl servers. all of the db interaction on
that stuff is handled by requests to internal perl-servers which
return json objects. its really gives us the best of both worlds.
On Jul 1, 2007, at 4:47 AM, Tony van der Hoff wrote:
On 30 Jun at 16:55 Jonathan Vanasco <[EMAIL PROTECTED]> wrote in
message
<[EMAIL PROTECTED]>
[snip]
assuming you're on a nix/bsd -- you need to be able to restart the
server.
if you can't , then you shouldn't be using mod_perl.
[snip]
Thank you, Jonathan, for your more detailed explanation. I have to
say, I am
extremely disappointed with my experience. I've used PHP for some
years to
create interactive web sites with some success, but having read
about the
significant performance boost available from mod_perl, I bit the
bullet, and
used PERL for the first time on my current project. Had I known
then what I
know now, I wouldn't have bothered :-(
I don't even like the language much, but I'm sure that's a personal
thing.
It looks then like I have two options:
1. abandon mod-perl and just use cgi.
2. move the project to a server over which I have full control.
(1) rather defeats the object of using PERL, and I am loth to
acknowledge
defeat; (2) adds significant expense, and extra effort, to the
project. Bah
- what a mess!
Thanks again, Tony
--
Tony van der Hoff | mailto:[EMAIL PROTECTED]
Buckinghamshire, England
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| CEO/Founder SyndiClick Networks
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| Founder/CTO/CVO
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
