fastcgi_vs_modperl

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.

===



the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu