Another mod_perl user here! I've looked at FastCGI, but ongoing management has always looked to be more complecated than just altering the apache config.
We have a multi-server setup with hardware load-balancers. They balance between two threaded apache servers which serve all static files and then using mod_proxy, pass other requests via the load balancer again to the three apache/mod_perl/catalyst servers. (We did it with mod_proxy_balancer for a while, but found the hardware load-balancer did a better job). The front apache servers are configured for maximum threads, with Keep-Alive on and very high connection timeouts. The mod_perl servers are configured with the usual pre-fork and Keep-Alive off. We maximise buffers in the front-end to release the mod_perl process as soon as they can to handle another request. We generally restart the mod_perl servers in turn, so although there's a slow restart that's invisible to end users. Should there be a problem with all the servers the front apache gets a 502 proxy error, so we replace that with a pretty page. One of the advantages of mod_perl is that you only have a single instance of perl running, so you only have code in common to your apps loaded once (so that covers everything from core and CPAN as well as bespoke common code.) If we want to run a slightly different version of a codebase we use "PerlOptions +Parent" which gives you a separate perl interpreter for a particular vhost. Now I wouldn't say this is a good setup for *everybody* to use, but certainly there's a class of users where this type of setup will work very well. Carl _______________________________________________ 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/
