Thanks No, I haven't heard of PSGI/Plack, before you mentioned it. It sounds intriguing, so it is tacked onto a rather long list of things I ought to investigate. I wasn't asking why others lstudy these things. Rather, I was asking how these options relate to each other, if at all. For example, I have read that I need not change my use of DBI in order to use Apache::DBI, as DBI will use it automagically if mod_perl and Apache::DBI are both installed (I guess, with what I read since my question, it reduces to a question of whether or not I'll see a payoff by trying to use fastcgi too). But, how, for example, do fastcgi and mod_perl relate? Are they competitors? Complementary? I have been using CGI for a while, and want to improve the responsiveness of my scripts. For that reason, in addition to studying mod_perl, I am also investigating use of JavaScript+jQuery+ajax (and I am thinking possible using mod_perl handlers to return XML to my JavaScript AJAX event handlers). I have now read some of the references you cite, and am working on the others? :-) Thanks again Ted
| [reply] |
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.
| [reply] |
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
| [reply] |
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
| [reply] |