Conf. multiple apache locations with colliding namespaces

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:


PerlSwitches -I /some/path/v2.0.0/
PerlResponseHandler run



PerlSwitches -I /some/path/v2.0.1/
PerlResponseHandler run


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:


PerlSwitches -I /some/path/$0/
PerlResponseHandler run


Any help is very much appreciated

cheers,

~ F

Re: Conf. multiple apache locations with colliding namespaces

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:
>
>
> =A0 =A0 =A0 =A0PerlSwitches -I /some/path/v2.0.0/
> =A0 =A0 =A0 =A0PerlResponseHandler run
>
>
>
> =A0 =A0 =A0 =A0PerlSwitches -I /some/path/v2.0.1/
> =A0 =A0 =A0 =A0PerlResponseHandler run
>

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_Pa rent_

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 constant=
ly
> 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

Re: Conf. multiple apache locations with colliding namespaces

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