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

Reply via email to