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
pgpDwReglQIB7.pgp
Description: PGP signature
_______________________________________________ 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/
