On Fri, Feb 27, 2009 at 5:30 AM, Carl Johnstone <modp...@fadetoblack.me.uk> wrote: > The thing is that as I'm running the app under Catalyst, once I've started > splitting off into different server instances, there's not as much of an > advantage in using mod_perl - I can use FastCGI or HTTP::Prefork or even > just run catalyst_server.pl.
Well, you probably could run it on FastCGI now. I don't think this really changes much. You wouldn't want to make every single app use a different FastCGI backend because it would waste memory, so either way you'll want to group things together as much as possible. Some people have suggested using the interpreter config options to start different interpreters for different virtual hosts. I haven't tried that and I'm not sure it works. (Also, you'd be nuts to run anything serious on HTTP::Prefork.) > Although we don't have a huge amount of code we have a lot of Controllers > inheriting from base classes - checking the 3 main culprit apps they contain > ~500 Controllers between them. As it's built up gradually I've always just > presumed the overhead was from that. 1500 classes is not enough code to cause a 2 minute compile on modern hardware. I've heard people say that DBIx::Class has a slow startup, so if you use that you might look there first. > Actually I think the hardware load-balancing we've got does that - so rather > than getting apache to balance, I should probably feed the requests back > through that. You mean go directly to mod_perl? You'd still want a front-end proxy for buffering. I'd suggest checking with the mod_proxy_balancer people to see if they have a solution. One trick I've used is to make my front end check a specific URL on the backend for alive-ness. When I want to remove a backend from the pool, I just move the file aside and put it back when the server has restarted. - Perrin
