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:[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > http://nothingmuch.woobling.org 0xEBD27418
_______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
