http://qs321.pair.com?node_id=31089

rodry has asked for the wisdom of the Perl Monks concerning the following question:

I ran into a post from Merlyn that said, in other words, that he would not think of developing any serious project if it was not with mod_perl and APACHE::DBI.

I asked him about it and he gave me good reasons to back up what he said. But I was left wondering why is not that much mention on this site about it.

Also, I would like to know if the CGI/PERL combination is so inadequate, why would anyone be spending any time developing in it? I am halfway into the development of a project and now I am considering taking mod_perl and APACHE::DBI into account.

I wonder how many of my scripts I will have to re-write.

Replies are listed 'Best First'.
Re: mod_perl: Is it so necessary?
by merlyn (Sage) on Sep 05, 2000 at 09:27 UTC
    CGI is simple, easy to understand, and fairly portable, since it's just an interface between the web server and a child process that reads the environment and standard input, and provides a simple text interface on standard output.

    But to get performance, we can't fork on each request. That's the death knell. So many "servlet"-type solutions have arisen, with probably the most popular being the mod_perl under Apache. After all, that's what The Monestary uses. {grin}

    -- Randal L. Schwartz, Perl hacker

RE: mod_perl: Is it so necessary?
by KM (Priest) on Sep 05, 2000 at 18:46 UTC
    It isn't that it is inadequate (CGI/Perl, that is), but rather that many applications may not need mod_perl. A simple guestbook, file manager, calendar, etc... may not need the speed enhancements, caching, response/logging phase massaging, etc... that mod_perl provides. mod_perl does add some bloat, which isn't always needed.

    People need to do things with the right tools, and mod_perl is Just Another Tool. It is also a valuable tool which provides functionalities which 'regular' CGI/Perl does not. Or at least provides a more efficient way to do some things (for example, you *can* write to the http log file with CGI/Perl, but mod_perl provides a better way).

    Whenever speed/response time is an issue with a CGI application, you should take mod_perl (or fastCGI) into account and see if those tools will help build a better web application.

    Cheers,
    KM

Re: mod_perl: Is it so necessary?
by cianoz (Friar) on Sep 05, 2000 at 17:49 UTC
    you wrote: Also, I would like to know if the CGI/PERL combination is so inadequate, why would anyone be spending any time developing in it?
    Immagine you have to run the script with a different UID from that of the web server: a cgi script can be run suid,
    instead a mod_perl script runs inside the httpd process with the same UID.

    an other reason could be portability: cgi run almost everywhere, if you don't control the server where your script run maybe your oly choice is cgi.

Re: mod_perl: Is it so necessary?
by Anonymous Monk on Sep 05, 2000 at 12:56 UTC
    You wrote: I wonder how many of my scripts I will have to re-write.
    you can run your cgi scripts under Apache::Registry without changes
    taking advandage of persistent DB connections, fast startup etc. (whell, if the script run clean under "use strict" then it will do also under Apache::Registry...)
      if the script run clean under "use strict" then it will do also under Apache::Registry...

      Well, this is not necessary true. For example, my() scoped variables in nested subroutines are a problem. See the relevant section in the mod_perl guide.

      You might also look at Training wheels again why it is better to rewrite CGI scripts to modperl apps. The mod_perl guide has a nice section about tuning, too.

Re: mod_perl: Is it so necessary?
by TheoPetersen (Priest) on Sep 06, 2000 at 00:12 UTC
    Before moving a script to Apache::Registry (or rewriting it as a mod_perl module) ask yourself: do all my Apache child processes need this? If the answer is yes, then go ahead; if not, leave it as a simple CGI.

    Since Apache::Registry caches compiled scripts (well, it just leaves them compiled, more accurately) and mod_perl never releases compiled code (any more than a regular Perl interpreter does) anything you run either way is going to add memory for the life of the child it runs in. Occasional admin scripts, once-a-day statistics and that sort of thing should remain plain CGI for that reason.

    ..Theo

Re: mod_perl: Is it so necessary?
by Anonymous Monk on Sep 06, 2000 at 00:10 UTC
    Don't know about mod_perl, but one reason NOT to use DBI is that it may not exist on your target machine. Some of my scripts broke this morning when I moved them from development to production. It turns out that the production machine did not have DBI installed.

    Fortunately the 'Use DBI' statement was not needed, so commenting it out fixed the problem. But I would have been in big trouble if I had actually coded in DBI. Unless one has control over one's target environment or is reasonably certain about what it will be the less fancy modules used the better.

      I can't agree with that. Modules are there to make your life easier by reusing code as much as possible.

      If you can't get your client/boss/ISP/whatever to install whatever modules you need then you should seriously consider getting a new client/boss/ISP/whatever.

      --
      <http://www.dave.org.uk>

      European Perl Conference - Sept 22/24 2000, ICA, London
      <http://www.yapc.org/Europe/>
      That's just a problem with your infrastructure and machine builds nothing to do with the suitability of DBI
      So, if you didn't use DBI how do you intend to communicate with your database? Talk to the DB directly via sockets?!

      I do agree with trying to simplify things if you don't have control over the environment, but your example is buggy. Also, why not install the modules required locally within the area you do have control over?

      Sigh...