Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Why mod_perl is good for PHP

by Anonymous Monk
on Aug 03, 2003 at 00:10 UTC ( #280366=perlmeditation: print w/ replies, xml ) Need Help??

Since there are many ways to solve problems with Perl, why has no-one created a standalone server-side Perl engine that would be similar to PHP's Zend or Java's Tomcat?

mod_perl is very cool, but is out of the reach of individuals/organisations that want a dynamic website but cannot afford a dedicated server - not only does this defeat one of the main benefits of open source software (i.e. cost) it has also forced many Perl programmers to learn/migrate to PHP.

Comment on Why mod_perl is good for PHP
Re: Why mod_perl is good for PHP
by Beatnik (Parson) on Aug 03, 2003 at 00:53 UTC
    There are quite a number of perl based webservers out there. Ofcourse I'm extremly biased but I'm pretty confident mod_perl does things to Apache that no other programming language does with Apache (besides C ofcourse)

    Java might be the hype of the late 1990s and the early 2000 but it's still as slow as hell. It needs LOADS of hardware (which means a dedicated server). Also, Java is extremly bloated (initializing 3 classes to read from a file is just a tad too much of the good stuff for me). Using Servlets/JSPs/WARs in Java makes it even more complicated. If I was an individual or an organisation and I needed some 'dynamic' site but wouldn't want to spend some hard cash on hardware, I would not even consider Java.

    For PHP, as far as I know, Zend isn't even a true webserver engine... ofcourse you can (correct|downvote) me if I'm wrong.

    Over the past few months, I spend quite a few thousands lines of perl code on mod_perl and I love it. You can do dynamic sites with minimum effort in mod_perl. There are a few template tools that integrate quite nicely and give you the development speed and flexibility, not to mention a rather short development time frame.

    Just my biased €0.02

    Greetz
    Beatnik
    ... I'm belgian but I don't play one on TV.
      I'm pretty confident mod_perl does things to Apache that no other programming language does with Apache (besides C ofcourse)

      See mod_python.

      I don't have much to say about the rest of your post, but it strikes me odd that you took this as an opportunity to rail against Java. The only reason he even brought it up was to further explain his point. I see nothing in the OP talking about the relative merits or problems with that language. Curious you devoted a whole paragraph to unnecessarily pointing out its flaws.

        I actually spent the past 5 years doing some horrible Java tricks, including the whole webserver idea. I believe I know enough Java to judge it... I don't know PHP very well... I usually don't spend longer than 30 minutes looking at PHP code. I see some differences with perl and things that might be considered bad but I know too little about it to make an unbiased judgement. I hear some nice things about it, I hear some bad things about it. At the moment, with the very little I know about PHP, I'd still go for PHP in a PHP vs Java match. You can call me script addict any time soon now.

        Oh, BTW.. I'm not judging Python since I don't know it... but I CAN give you an overview of Things that suck about(TM) COBOL

        Yes, so I misspelled Python (thanks dws) but it was late :)

        Greetz
        Beatnik
        ... I'm belgian but I don't play one on TV.
Re: Why mod_perl is good for PHP
by jacques (Priest) on Aug 03, 2003 at 01:54 UTC
    I agree with you mostly. I am one of the many Perl hackers who had to learn PHP. But in a few years mod_perl will be replaced by mod_parrot, which should revolutionize a few things.

    mod_perl also suffers because its name contains the word "perl". Anything that contains the word "perl" or "cgi", is frowned upon and seen as archaic. Not everywhere, but in enough places to make you naucous.

    How about ... mod_zilla? Hmmmm... mod_thra? Oh, I know... mod_perl_2003 (but I guess that would entail insecurity)

Re: Why mod_perl is good for PHP
by trs80 (Priest) on Aug 03, 2003 at 03:40 UTC
    A troll?

    I don't feel the above comments are based on fact, but rather sound like someone trying to hinder the growth of Perl (mod_perl) or someone that is bitter about their experience with mod_perl.

    But in case this node is visited in the future, let me add my 2 cents to the pot.
    1. All the pieces exist for a Zend/Tomcat type "packaging" of mod_perl, but there are many entrenched users of mod_perl that don't have time to switch to a new methods. One of the reasons being that mod_perl predates (I believe) the other solutions mentioned
    2. mod_perl is NOT out of reach
    3. mod_perl is a full open source project which is not directly funded by an organization earning its revenue directly from its sales (use), unlike the two examples you provide. Therefore mod_perl is community/need driven rather then "packaging" driven.

      merlyn has talked about writing an aricle/guide/whatever on how to setup Template Toolkit 2 in a mod_perl environment to replace php. Since users aren't writing perl directly, the potential for users mucking up other users programs goes down ... it's not a bad idea (for ISPs or anyone who can't run a server per user...).

      As to your troll comments, I don't think it's a troll (but I do think it may be somebody trying to persuade merlyn to write this already in a somewhat subtle manner).

      MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
      I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
      ** The third rule of perl club is a statement of fact: pod is sexy.

        merlyn has talked about writing an aricle/guide/whatever on how to setup Template Toolkit 2 in a mod_perl environment to replace php.

        It will take more than an article or even a book.

        The masses want simple things. They don't even like to read.

        What is needed is an easy-to-use software tool that would set up such an environment with minimal prerequisites and effort.

Re: Why mod_perl is good for PHP
by mrd (Beadle) on Aug 03, 2003 at 15:13 UTC
    mod_perl is very cool, but is out of the reach of individuals/organisations that want a dynamic website but cannot afford a dedicated server
    That really bugs me too. I don't understand why you can get mod_php hosting for $2,50 while for mod_perl you have to pay at least $20,00/mo.

    ----
    A determined individual can write garbage code in any language. -- Alan Holub

      It's fairly simple if you look at it. Mod_Perl and Mod_PHP have basically nothing in common. Basically mod_php is simply Apache::Registry, or possibly even less. It simply embeds the php interpreter in apache so it doesn't have to start it up for each script it calls. Mod_Perl on the other hand allows you to write complete modules for apache. It's commonly mentioned as simply away to speed up perl scripts, which is where this commmon misconception comes from, but thats nothing compared to the true power of mod_perl. It basically lets you rewrite any part of the apache request model you want, just like any of the other apache modules. Which is why real mod_perl hosting is more expensive, because you basically have to provide one apache server per person who wants mod perl, as anyone running mod_perl scripts has to have access to configuration file for the entire server, and theres no way to 'cordon off' various mod_perl scripts from each other.

      Now what a hosting provider could do fairly easily is just set up Apache::Registry for each of it's clients in a certain directory,(and I think a few of them do this..) but that is nothing like mod_perl, it just a simple hack to speed up scripts.
        I know that you can do a lot more with mod_perl than with mod_php.

        But if I only want to generate content in a fast, memory persistent way, I don't need to step in and take over the other phases of a server response. Apache::Registry would be just perfect for this, and I don't agree that it is "a simple hack". Just because it's so easy to use it, doesn't mean that you can't build "real" web-sites with it.

        The fact we only have a choice between very cheap cgi scripts (with all their drawbacks) and a very expensive swiss-army knife is annoying.

        Now what a hosting provider could do fairly easily is just set up Apache::Registry for each of it's clients in a certain directory

        If it was that easy then most ISP would be doing it. Imagine a simple registry script that did this:

        package DBI; sub connect { die "This program requires Microsoft Windows..."; } 1;

        In perl you can write into any namespace that you like, and since mod_perl is persistant, then this new subroutine will hang around for as long as MaxRequestsPerChild determines, or until the server is restarted. So you can mess up anyone else that depends on DBI and is lucky enough to share a server with you.

        mod_perl is too closely integrated into Apache to make this safe, and perl has no concept of permissions on namespaces (rightfully so).

        However, all is not lost. mod_perl2 can solve this problem by using the perchild MPM where a fixed number of processes (that can run with different uids) create multiple threads to handle the requests. So each site that requires mod_perl will get their own playground that won't interfere with the other users.

        The problem is that this version has not stabilized yet, so we need to wait a little bit longer before we can use these features. I believe that once this has stabilized you will see mod_perl becoming available at a lot more ISPs...

        In the meantime, look at SpeedyCGI or FastCGI, which will do a lot to increase the speed of your perl scripts.

        Cees

Re: Why mod_perl is good for PHP
by CountZero (Bishop) on Aug 03, 2003 at 18:20 UTC

    What's wrong with Apache? It's Open Source, it's free, it sets up easily and it is the world's most used web-server, so what would stop anyone from using it?

    It can run Perl (through mod_perl), PHP (through mod_php) and Python (through mod_python, mod_snake and PyApache).

    Apache: "serve all, love all" (with my apologies to HardRock Cafe)

    CountZero

    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

      I noticed this briefly last week but didin't look into it. I think the new threaded Apache2/mod_perl2 allows you to keep a different (perl) interpreter thread for each virtual host. What this meant to me was that my hosting provider will now be able to give me a mod_perl environment to develop on because I will no longer be sharing a perl interpreter with their other customers. If this is true, then it has a more important meaning to me: the mod_perl2 developers had this problem in mind when designing mp2 so there will be a lot of new benefits for people who don't host their own servers.

      $will->code for @food or $$;

Re: Why mod_perl is good for PHP
by barrachois (Pilgrim) on Aug 04, 2003 at 00:39 UTC
    Have you looked at SpeedyCGI?

    While it isn't a stand-alone engine, it does give you much of mod_perl's benefits (e.g. a persistent perl process) without requiring any modification of the underlying web server. I've installed and used it entirely within a user account, without any system privileges, and it serves up my HTML::Mason pages with respectable performance. - barrachois

Re: Why mod_perl is good for PHP
by bm (Hermit) on Aug 04, 2003 at 16:21 UTC
    This thread reminds me of a very similar thread on c.l.p.m recently.

    Now I wonder if this is the same OP?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://280366]
Approved by Corion
Front-paged by hsmyers
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (4)
As of 2014-11-23 13:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (132 votes), past polls