This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: re: mod_perl vs. FastCGI From: "Scott Thomason" <SThomaso@hii.com> Date: Wed, 21 Jun 2000 15:55:51 -0500 You said: > Most people on this list probably have already determined that > mod_perl is better for their own needs. That`s why I`m here, at > least. > > But "better" is a very subjective term, and you need to define your > parameters. What are your goals, what are your constraints, what is > your experience, etc., are all questions you need to answer before you > can decide whether one technology is more suitable for you to use on a > given project than any other technology. OK, my goal is simple: I want my Perl scripts to run lightening fast, ideally without bloating the memory requirements of my webserver. I'm a good Perl developer. I've used mod_perl a little in the past, and spent many agonizing hours cleaning up one-shot CGI scripts so they would work (and on some, I just plain gave up and let them run slow). Last project, I gave FastCGI a whirl (via mod_fastcgi and CGI::Fast) and was delightfully surprised to find there was no headache involved, only benefit. Which got me to wondering, why all the buzz over Apache::Registry if FastCGI offers the same speed without the server bloat or coding restrictions? So, given that, here's the question again: why would you choose Apache::Registry over FastCGI? I want to be a believer... === Subject: RE: mod_perl vs. FastCGI From: Jerrad Pierce <Jerrad.Pierce@networkengines.com> Date: Wed, 21 Jun 2000 16:57:55 -0400 There was a recent article in WebTechniques comparing the two http://www.webtechniques.com/archives/2000/05/infrrevu/ === Subject: re: mod_perl vs. FastCGI From: Vivek Khera <khera@kciLink.com> Date: Wed, 21 Jun 2000 17:08:03 -0400 (EDT) ST" == Scott Thomason <SThomaso@hii.com> writes: ST> in the past, and spent many agonizing hours cleaning up one-shot ST> CGI scripts so they would work (and on some, I just plain gave up ST> and let them run slow). Last project, I gave FastCGI a whirl (via I wonder how these scripts on which you gave up would work with FastCGI. I suspect they have memory leaks. If you write your perl programs well, that is, with "use strict" and warnings turned on, and you get a clean execution, then moving those to mod_perl is pretty much trivial. You just need to be careful about global variables. Another reason to use mod_perl is that you're not just getting the ability to write CGI programs. You get the ability to interact with Apache at *any* phase of its API using perl. That is, if I want to write my own authentication mechanism, I can do it in perl. I don't think you can accomplish that in FastCGI, since this is not a CGI operation, it is a web-server operation. === Subject: re: mod_perl vs. FastCGI From: "Scott Thomason" <SThomaso@hii.com> Date: Wed, 21 Jun 2000 16:16:32 -0500 Actually, I recently finished a FastCGI authenticator. The mod_fastcgi module provides the equivalent hooks into the Apache authentication mechanism. It allows you to configure httpd.conf in a manner nearly identical to normal basic authentication. But the question remains: for speed, why Apache::Registry over FastCGI? It wasn't memory leaks that gave me headaches with mod_perl...I couldn't get the scripts to work correctly at all. I strongly suspect some obtuse use of globals was screwing me up and causing the scripts to malfunction, but the script was too big, elaborate, and messy for me to find it and I had to move on without the benefit of mod_perl. === Subject: re: mod_perl vs. FastCGI From: Perrin Harkins <perrin@primenet.com> Date: Wed, 21 Jun 2000 14:43:19 -0700 (PDT) On Wed, 21 Jun 2000, Scott Thomason wrote: > So, given that, here's the question again: why would you choose > Apache::Registry over FastCGI? If you're developing from scratch, why would you choose Apache::Registry at all when you can write directly to the Apache API with a mod_perl handler? But that's beside the point. If you search the Geocrawler archive (I prefer the one at Swarthmore, but it's down right now) you'll get about 200 hits back for "fastcgi" and you'll probably get some on the fastcgi archive searching for "mod_perl". There's a fair amount of commentary there on both sides. The conclusion I reached was that running mod_perl with a reverse proxy in front of it was nearly identical to running fastcgi, but there are more interesting modules available for mod_perl at this point, and a larger developer community. I don't know if things like the debugger and profiler work with fastcgi, but they do work with mod_perl. There are lots of CPAN modules to do things you'll probably want, like Apache::SSI, Apache::Status, Apache::Resource, Apache::Request, etc. My caveat is that I've never put a fastcgi system into production so I have only a passing familiarity with it. === Subject: Re: mod_perl vs. FastCGI From: Devin Ben-Hur <dbenhur@eMerchandise.com> Date: Wed, 21 Jun 2000 15:39:29 -0700 Scott Thomason wrote: > So, given that, here's the question again: why would you choose Apache::Registry over FastCGI? I want to be a believer... First, I don't really recommend Registry, if you're serious about your system you should use the direct handler interface and not just port a bunch of crufty old CGI scripts. Back in 96/97, I built an ecommerce engine using FastCGI & Perl. Today my company runs its site on Apache/mod_perl. Both technologies address some similar concerns and are designed to reduce execution overhead and enable persistent application servers to communicate with and modify the behavior of web servers. FastCGI is a protocol for a web server to communicate with an application server over network sockets. It also includes some primitive process management facility, I believe. mod_perl is an in-process integration of the Perl interpreter with the Apache web server. When I was using FastCGI, mod_perl was relatively immature. FastCGI worked but also was suffering from the support abandonment of its inventor Open Market. We had to debug several problems with the open source FastCGI code in our environment and there was relatively little support. But we got it to work, and it did work well in production. When we set out to implement our second generation ecommerce engine, we re-evaluated and choose to use mod_perl primarily because it had accumulated a vastly larger user base, resulting in a more mature environment and far superior support resources. I still think this is mod_perl's chief advantage over FastCGI. I've never worried over-much about porting old CGI scripts to either environment so can't speak to either technology's efficacy for this use. FastCGI pros: Web-server independant Language independant mod_perl pros: Larger user base, more real-world implementations More extensive support infrastruction: the guide, this list, etc. Extensive library of modular extensions which have been designed and tested to be used in the mod_perl environment Greater web server integration -- 14 handler hooks for mod_perl: PerlChildInitHandler PerlPostReadRequestHandler PerlInitHandler PerlTransHandler PerlHeaderParserHandler PerlAccessHandler PerlAuthenHandler PerlAuthzHandler PerlTypeHandler PerlFixupHandler PerlHandler PerlLogHandler PerlCleanupHandler PerlChildExitHandler vs 3 server hooks for FastCGI: Responder Authorizer Filter Which one to use should depend on what your needs and experience are. Properly tuned implementations of either will have very similar performance and resource utilization characteristics. ===