Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Mod Perl info

by hok_si_la (Curate)
on Feb 09, 2005 at 16:29 UTC ( #429412=perlquestion: print w/replies, xml ) Need Help??
hok_si_la has asked for the wisdom of the Perl Monks concerning the following question:

Major Tom to ground control,

I recently read that Mod_Perl should be used when concerned with program speed. There was some vague information about intitial call compilation and the byte code residing in RAM. Can anybody give me the skinny on this? Is Mod_Perl generally faster than PHPx?


Replies are listed 'Best First'.
Re: Mod Perl info
by jbrugger (Parson) on Feb 09, 2005 at 16:40 UTC
    It would be nice to see, if you did at least some research. have a look at, to read about mod-perl.
    About speed? it all depends on what exactly you're trying to do, but a good build programm running on mod-perl indeed is fast (notice that fast is relative).
    if you want to know what mod perl is, read it.
Re: Mod Perl info
by cowboy (Friar) on Feb 09, 2005 at 16:42 UTC
    With mod_perl, you have more control over the apache request, and are able to do processing at almost any stage.

    You also have the benefit of not having to fork and start up a perl interpreter, as it is already loaded into memory. This can give you a significant speed increase, at the cost of a fatter apache process.

    If you are looking at mod_perl, these links may help.
    • mod_perl - The mod_perl site.
    • Mason - A templating/web development system

    As for speed, most benchmarks I've seen, mod_php was faster for small things (hello world type stuff - less overhead).
    Of course, generally dynamic applications are constrained by databases and the like, rather than perl/php speed.

    Update: To clarify above notes, with php (at least up to php4, I'm not all that familiar with 5), you have much more control over apache with mod_perl, than mod_php.
    Furthermore, speed isn't really an issue. If mod_perl is too slow, odds are php is too slow as well, and you might start considering a standard C apache module.
Re: Mod Perl info
by RazorbladeBidet (Friar) on Feb 09, 2005 at 16:44 UTC
    There is a plethora of information at the sites mentioned above and online elsewhere. Basically the perl interpreter stays resident in memory which decreases overhead but can increase the complexity of your scripts. From what I've read (haven't seen any benchmarks) PHP and mod_perl offer similar timings. I think the choice will be more about language preference.
      Thanks for the pointers. I will RTFM on it.
Re: Mod Perl info
by samizdat (Vicar) on Feb 09, 2005 at 20:37 UTC
    As an addendum, most Apache users link mod_php4/5 into their Apache, so you should compare apples to apples. My experience has been that php programs are leaner; however, php has less power. For web-only or web+db-only apps, PHP is great, but for gluey things that wander all over your system capapbilities map, Perl is king. It's more a matter of capabilities you need (and prefer) than speed. In general, the Apache module of anything webified will be much faster.
Re: Mod Perl info
by TedPride (Priest) on Feb 09, 2005 at 19:26 UTC
    PHP is just simpler if you want to include small snippets of code in a page. I know some people think mixing code and text is evil, and advocate template systems instead, but those are always more complex and require more overhead. I tend to use Perl more for complicated algorithms and admin functions where the displayed results don't have to be pretty, since you can usually write the same code in half the space using Perl instead of PHP. Both languages have their uses.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://429412]
Approved by monkey_boy
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (6)
As of 2018-06-25 00:48 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (126 votes). Check out past polls.