On Apr 11, 2007, at 11:23 AM, Chris Hagglund wrote:
I'm having trouble figuring out the right mix of configuration
settings to do what I want, which is to have 5 separate sets
libraries (DEV, TEST, PROD, developer1_personal_dev,
developer2_personal_dev) get shared by a large number of vhosts.
The way I am doing it now is each vhost Include's the appropriate
mod_perl config file for whatever set of libs it needs to be on.
The Include'd files each will do PerlOptions +Parent and
PerlSwitches -Mlib=/path/to/specific/libs and then load a bunch of
PerlModules from those libs.
Are you aware of the dangers in namespace collision this can cause?
You're going to run into problems when DEV & PROD have different
versions of the same module -- only one will load.
The trouble is, as each vhost loads this config file for its plain
and SSL vhost directives, the amount of memory being used seems to
be going up, and restarting apache is taking longer and longer.
never restart apache. stop it, then start it. but never restart it
( ie : apachectl graceful || apachectl restart )
Intead of loading it over and over again (twice for vhosts with
ssl!) I am hoping to find a way to tell apache to load PROD mp
configuration, then load 100 PROD vhosts that will all share it,
then load TEST mp configuration, then load 20 vhosts that use those
libs, etc, but I am getting error like: 'mod_perl is already
running, too late for PerlSwitches' when I am trying to start
setting this up.
Am I doing something wrong, or is there an esablished best-practice
for doing this kind of thing?
I think you're best off with running something on port 80 -- either
apache / squid / nginx that handles proxying to multiple apache
+mod_perl backends
1 for prod, 1 for test, 1 for dev etc
Con:
you're going to use more memory doing that -- each apache will
load its own version of the common libraries.
Pro:
a- right now your entire system can fail because of a bug in 1
module. if someone has a serious bug in dev or or personal_dev, they
can bring down everything
b- you can better balance your resources: give the testing/dev
stuff a short max memory and run fewer instances -- free up memory
for the production system. right now your system is blocking
production resources for 4 versions of testing systems. thats kind
of insane.
c- for dev stuff, you're often better using 1 or two httpds MAX.
its damn crazy trying to debug otherwise.
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
