Beefy Boxes and Bandwidth Generously Provided by pair Networks vroom
P is for Practical
 
PerlMonks  

Re^3: puzzling problem with access to DB when using mod_perl

by Anonymous Monk
on Dec 29, 2012 at 10:18 UTC ( #1010808=note: print w/ replies, xml ) Need Help??


in reply to Re^2: puzzling problem with access to DB when using mod_perl
in thread puzzling problem with access to DB when using mod_perl

You could say they are competitors.

mod_perl is a way to embed Perl code into Apache. It also opens up some of Apache's internals for Perl. FastCGI uses a persistent process to handle CGI requests. Both reduce the overhead in running a dynamic script, but mod_perl encompasses much more than FastCGI.

I have played around with mod_perl a bit and think it is too heavy-weight for what people usually call "web programming". I would say it was made for doing pre-request stuff (things like rate limiting, filtering, request rewriting, and whatnot), but it's not the best way to do the things you expect for "plain" web programming. Using it that way also makes your Apache instance much fatter if you ever use much memory in any single one of your scripts.

Of course, FastCGI is not much better in the memory use case, but since it is a separate process, its restarting is easier (and usually automatic). Another bonus point for it is that it is not dependent on Apache, but can run on pretty much all the common web servers.

If you are looking for an easy way of boosting the speed of some existing CGI scripts, try mod_perl -- it has a pre-written handler for those kinds of scripts. Otherwise, the current fad is PSGI/Plack and some sort of backend such as FastCGI to go with it.


Comment on Re^3: puzzling problem with access to DB when using mod_perl
Re^4: puzzling problem with access to DB when using mod_perl
by Anonymous Monk on Dec 29, 2012 at 11:24 UTC

    Otherwise, the current fad is PSGI/Plack and some sort of backend such as FastCGI to go with it.

    It is not a fad. Instead of writing for CGI or FCGI or mod_perl1 or mod_perl2 or Catalyst or ... , you simply target PSGI

Re^4: puzzling problem with access to DB when using mod_perl
by ted.byers (Scribe) on Dec 29, 2012 at 19:31 UTC

    Thanks for this.

    It would seem, then, that my incorporation of mod_perl scripts into my web apps will need to depend on precisely on what I need to do.

    I won't write off FastCGI, as, based on what I have been reading, I can write C++ programs and have them invoked by it. Thus, I ought to be able to use the C++ connector for my DB to make a connection (or connection pool), and then use my favourite C++ idioms to do one statistical analysis or another of the data retrieved from the DB, returning only the results of the analysis to the web page (and this probably mediated from a JavaScript AJAX call). I know this is a Perl forum, but the fact is that with some of the statistical analyses I do, I can get order of magnitude better performance from my best C++ code than I can with perl; and this makes some kinds of reporting within a web application feasible (in terms of a result in less than a minute VS a result in 20 minutes - I know I could implement my algorithms in C++ withn the bowels of a Perl module, but why, when the analyses are very specialized, and probably not particularly useful for anyone other than myself).

    I guess at present my best options are to use mod_perl for some things and to change all my usages of DBI->connect(...) to DBI->connect_cached(...)

    Thanks again

    Ted

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1010808]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (7)
As of 2014-04-16 05:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (414 votes), past polls