[Catalyst] Why use external FastCGI apps?

[Matt Pitts]

Thanks for explanation, this makes a lot of sense to me. 

Does anyone know if Apache's mpm_worker is compatible with mod_fastcgi and external fastcgi? Is there any real benefit of threads in this scenario?

v/r
-matt pitts

> -----Original Message-----
> From: Yuval Kogman [mailto:nothingmuch at woobling.org]
> Sent: Thursday, February 07, 2008 12:23 PM
> To: The elegant MVC web framework
> Subject: Re: [Catalyst] Why use external FastCGI apps?
> 
> On Thu, Feb 07, 2008 at 11:46:36 -0500, Matt Pitts wrote:
> > Why is it so much better to have fastcgi as an external process?
> 
> In my experience it has been much simpler to set up the fcgi processes
> as separate entities, simply because the heap of config sh*t is less
> monolithic.
> 
> Conceptually it's a bit more like the webserver is a reverse proxy for
> several application specific web servers, and it doesn't try to meddle
> with their business in any way.
> 
> This means you can restart apps independantly, easily manipulate the
> environment (which perl runs it, etc), without bothering to do it in a
> roundabout way by specifying what you want in the http server's silly
> configuration language.
> 
> This simplicity has paid off for me simply in configuration time -
> there is far less black magic, figuring out who is calling who, etc.
> It's easy to figure out where the problem lies, and how to go about
> fixing it quickly. When the webserver is also the process manager
> things can get nasty.
> 
> > What's wrong with having mod_fcgid do its process management. If I'm
> > not mistaken good process management is one of the design goals of
> > this project.
> 
> Finally, it's also a bit tricky to figure out when/where the actual
> listen/fork calls are made. With a standalone fcgi server the perl side
> is in control of the forking, so you can be 100% sure you can benefit
> from page copy on write (less memory).
> 
> I don't know about mod_fcgid but both apache and lighttpd's builtin
> fastcgi + process management from the webserver couldn't support this
> and I doubt they ever will be able to, the fork just has to happen too
> early.
> 
> > Why did we chose mod_fcgid? Well, I tried playing around with
> > mod_fastcgi for awhile and had problems getting the config straight -
> > admittedly due to a lack of knowledge on my part. Then I read some
> > tidbits about mod_fcgid being "better", so I tried it out and it
> "just
> > worked" and has been "just working" ever since.
> 
> I had the same Just Works™ behavior with sockets, which is why I
> switched from apache/lighttpd in the managed setup to standalone.
> 
> > I'm one of those folks who hates writing/managing his own daemon
> > management scripts, so if something is going to do it for me and it
> > works then I'm happy to use it.
> 
> you can easily cargo cult an /init.d for this, the catalyst fastcgi
> script will do the actual process management on it's own (including
> writing a PID file, etc). Look at its command line options.
> 
> --
>   Yuval Kogman <nothingmuch at woobling.org>
> http://nothingmuch.woobling.org  0xEBD27418