so my question is... Are there any other reasons that you might choose one exclusively over the other?

reasons you would want to use mod_perl:

• you need to have access to other parts of the apache request cycle besides just content production. eg, you need to hook into the authentication layer or the logging layer.
• your app will be hit frequently and needs to have low latency in the response.
• your app would benefit from in-memory persistence.

reasons to stick to CGI:

• it needs to be deployable on servers where mod_perl isn't available (of course, with Apache::Registry, you can still deploy any CGI script with mod_perl)
• the app will not be hit very often and doesn't need to be very fast, but perhaps will consume a very large amount of memory when it is run. an example would be a CMS or weblog backend that publishes to static html. the 'publish' or 'rebuild site' part probably has to do a lot of work and could use a lot of memory for a big site, but will only be run every once in a while. if you run it under mod_perl, it will bloat the apache processes and you may run into memory problems. CGI has the advantage of giving up all its memory when it's done.

those are just some of the reasons that i've deployed one way or the other in the past. others can probably come up with other reasons.

I think your question should be: Which do you use and why, mod_perl vs CGI?

CGI.pm is a specific module which does a phethora of things related to interactive web site programming which is not limited to either mod_perl or CGI programming.

CGI in the generic, perl centric, sense is a perl script which is fed the input from a users web request via the CGI (1.1 for example) specification. Then the standard output of the script is hooked back to the server which may or may not 'adjust' it a little and then send it along to the requester.

mod_perl in the generic sense goes from a more or less persistant CGI kind of model up to notionally writing subroutines which are dynamically loaded into your web server which happen to be written in perl.

mod_perl in general has a response time benefit over CGI scripts. Specifically, the totally mod_perl (which means writing a sub handler{...}, making entries into httpd.conf etc), allows the script to remain loaded into memory and even to retain persistant database connections for example. This kind of integration means that to to a database query, the script merely hands the query off to the already open database connection and gets the rows back. Depending on how long it takes to set up the connection, this can save major time on a per request basis. However, this does come at a cost. Your script needs to meet a higher coding standard then a CGI called script does since the mod_perl version, being persistant, will be called many times without the clean-up a CGI script gets when the perl interpreter exits and restarts for each request. Using the less total mod_perl immersion (Apache::Registry for example) where you get a faster than CGI and slower than mod_perl standalone script, there are settings you can use to get the server to clean up the memory space for you between requests.

Summary: CGI being the baseline for comparison.

mod_perl: Speed: faster -> vastly faster, Complexity: bit more -> somewhat more complex. Memory: with the total integration method, the server keeps all the functions and their related data storage in its address space, so it can get large.

If your script will run under use strict, you are much of the way to the mod_perl level of complexity, so it's not all that much of a step. Remember that variables are not cleared out for you at script end. If you use subroutine scoped lexical variables everywhere, this isn't an issue. Also, be aware that if you have persistant database connections and apache fires up 100 children that you may have that many open connections even though not all of them are doing queries. If you have more than one database it could be children * databases of open connections.

A mod_perl application can still use CGI.pm - I do it all the time. I write what are essentially CGI applications but I run them under mod_perl for the performance advantage. I can - however, run the same app in a non mod_perl environment quite easily.

If you write a mod_perl handler based application then it can only run under mod_perl. It is purely a case of how you wish to utilise mod_perl.

jdtoronto

CGI.pm can be used in combination with mod_perl, so it seems abit odd you should ask to choose one over the other. Maybe you meant to ask whether a programme should run as a standalone CGI application or a mod_perl application?

As a rule of thumb, mod_perl might help you with some performance issues and the sharing of data, when you run a large application with a lot of web requests.

Cheers, Sören

From this updated comment: "... I don't have web admin rights and I don't want them .."

I think that the answer is quite clear. You don't want mod_perl.

"Are there any other reasons that you might choose one exclusively over the other?"

Yes. If i have root access, and plan on coding up a fair sized web app, i will choose mod_perl. If it's just for an example, then i choose CGI.pm (well, to be technically correct, plain jane Apache). If i don't have root access, such as my perlmonk.org account, then i don't bother with mod_perl at all.

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

. . . then I really don't have the option to use mod_perl.

In the case you setup, that is true. I'm not sure what your point is, though. If you can't use mod_perl, then you can't use it, so you don't even need to ask.

Are there any other reasons that you might choose one exclusively over the other?

IMHO, mod_cgi should only be used for legacy code. mod_perl might need a little more discipline to use correctly, but the advantages are well worth it. Not just for speed, but for extra flexibility.

Yes, definitely take a look at SpeedyCGI if you're not able to use mod_perl. (Think of it as mod_perl without the headaches.) If you're using strict properly and cleaning up after your globals, you can often use the script as-is without any modifications.

• If you can write and use a dedicated mod_perl handler, do it. It has the best performance of all.
• Second choice should be a CGI script running under the "registry"-handler. The performance is still good, but you must take care in writing the CGI-script as there can be --as certainly you know-- some issues with repeatedly executing such scripts.
• If none of the above is possible: use a classic CGI-approach.

But in real world, I need to learn a lot more about perl and cgi to get some simple job of programmer. And I need all my time to learn to deal with simple tools.

So, I am leaving the mod-perl lessons for a better time of my life. It is actually more interesting to manage yourself with common things (at least, adding some new PMs). What is the rush of learning PHP or JAVA when the chances are low of finding a cheap server configured that way?

so my question is... Are there any other reasons that you might choose one exclusively over the other?

My work involves a single web server supporting many clients as virtual hosts, each running an individual installation of the same application. Between them, the clients are running several different versions of the application, and I therefore cannot use mod_perl v1 because it won't (as I understand it) cope with the need to distinguish between multiple versions of the same module.

I believe that mod_perl v2 incorporates a solution for this, but I haven't yet had time to investigate that. For now, it all runs with CGI.

Hugo