Perrin Harkins wrote: > You can't run two modules with the same name in the same perl > interpreter, so you either need to change the namespaces for > different versions or run separate servers.
Yeah it's a pity that the perchild mpm never moved out of experimental. In theory something like loading different versions of modules in each child after the fork could solve the main part of the problem. 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. > Two minutes? That's a very long load time. I've seen huge codebases > load in 10-20 seconds. I think something might be wrong there, like a > slow database connection or DNS lookup. I'll do some profiling. 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. > Is the real problem that apache is accepting connections during > startup? Yes. The actual restarting to load updated code is reasonably automated so I'm not sitting waiting. I have had complaints that whilst it's happening the sites seem to freeze. > You could solve that by making your front-end smarter. Some > systems, like perlbal, will wait until apache responds to a HEAD > request before considering a server up. 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. As ever, thanks for your advice Perrin. Carl
