Conf. multiple apache locations with colliding namespaces

[Fredrik Lindmark <fr...@capestream.se>]

Hello,

Apache is my weak hand so hope to clear some fog with your help.
we're looking for a way to offer version handling to our serverside  
perl app.
Each database is tagged to a certain version of the application and  
they should be upgraded individually to interfere as little as  
possible with the service
My first ideas goes as:

<Location /myApp-v2.0.0/>
	PerlSwitches -I /some/path/v2.0.0/
	PerlResponseHandler run
</Location>

<Location /myApp-v2.0.1/>
	PerlSwitches -I /some/path/v2.0.1/
	PerlResponseHandler run
</Location>

but came up with a number of conserns.

* the perl moduls namespace ought to collide unless each location  
scope are well isolated from eachother. will apache handle it?
Alt. solutions are rename each package to be version unique. but its  
neither time efficient nor pretty, would prefer a more straightforward  
folder categorization.

* we use worker mpm for memory sharing.  i dont see any problem with  
multiple simultanious code base tough, fill me in if i might oversee  
something

* 100+ versions of the app is quite likely to exist before dropping  
the backend.
will make it 100x the initial apps memory. Could this be an apache  
performance issue?

* to lanch a new version i prefer to not alter the apache config  
constantly
is there a way to make this dynamically?

searched around but could just find mass vhosts fixups
looking for something similar to:

<Location /myApp-*/>
	PerlSwitches -I /some/path/$0/
	PerlResponseHandler run
</Location>

Any help is very much appreciated

cheers,

~ F

Re: Conf. multiple apache locations with colliding namespaces

[Michael Peters <mp...@plusthree.com>]

Perrin Harkins wrote:

> You can also run separate mod_perl backends 

I usually like this approach since it gives you a lot of control and let's you 
manipulate (start, stop, etc) one instance without having to affect others. It 
also gives you more scaling options as you can in the future easily split off 
some clients to other boxes as things grow. Just put a simple proxy in front of 
all these mod_perl processes to make things perform better and reduce the number 
of mod_perl processes you need.

But all of these processes does mean more RAM, so make sure you have lots. If 
you can a 64bit box will let you cram in more. Memory will almost definitely be 
your bottleneck since Perl sometimes trades memory for speed.

-- 
Michael Peters
Plus Three, LP

Re: Conf. multiple apache locations with colliding namespaces

[Perrin Harkins <ph...@gmail.com>]

Hi,

> we're looking for a way to offer version handling to our serverside perl
> app.

You'll find many discussions of this in the mailing archive with
multiple options.

> My first ideas goes as:
>
> <Location /myApp-v2.0.0/>
>        PerlSwitches -I /some/path/v2.0.0/
>        PerlResponseHandler run
> </Location>
>
> <Location /myApp-v2.0.1/>
>        PerlSwitches -I /some/path/v2.0.1/
>        PerlResponseHandler run
> </Location>

That won't work.  Those use the same perl interpreter and it can't
load multiple versions of the same module.

> Alt. solutions are rename each package to be version unique.

That will work.

You can also run separate mod_perl backends, or you can create
additional interpreters with this:
http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_

Keep in mind, that will make your processes grow considerably.

> * we use worker mpm for memory sharing.

What do you mean by memory sharing?  Shared variables?  FYI, worker
normally uses more memory than prefork on unix systems because of
copy-on-write.

> * 100+ versions of the app is quite likely to exist before dropping the
> backend.
> will make it 100x the initial apps memory. Could this be an apache
> performance issue?

It will certainly use a lot of RAM, so make sure you have it.

> * to lanch a new version i prefer to not alter the apache config constantly
> is there a way to make this dynamically?

There's all kind of conf manipulation stuff in mod_perl.  I don't use
any of it, so I'll leave that to someone else.  I prefer to use
templates to generate the conf files, so they're easier to see and
debug.

- Perrin