mod_perl implementation possibility

hello,

i am doing a little research on adopting Perl into our
dev group.

we are a small team (8) that mostly programming in
Java . since half of the team has a little or ok
knowlege of Perl, we have been experimenting Perl in
smaller projects to avoid a lot of java related
overhead. most of our app are serving other department
staff or students (we are a big university)

current Perl projects are written in plain cgi and
hosted on one server serving small volume of people.

we are exploring the idea of writing medium to large
Perl apps in the future which will require mod_perl.
the current environment is apache 1.3. having read
modperl's doc and i am concerned about running
multiple unrelated mod_perl apps on one server, such
as 2 or 3 medium Perl apps. ( issue like database
handler pollution etc which i know little about )

mod_perl 2 seems solve the problem with virtual host
which will require us to adopt apache 2 and use
virtual host.

my understanding may be false but i would like to hear
your point of view and help me figure out the problem
we may have if we decide to use more Perl in our
development.

thanks,

James.



____________________________________________________________ ________________________
Get your own web address.
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

RE: mod_perl implementation possibility

hi=20

i'd encourage you to look into mod_perl as it can be amazing in letting
you get the most out of your hardware.

as far as running multiple unrelated perl apps using mod_perl- i think
it happens every day! you just need to program them accordingly. also,
you can use virtual hosts under apache 1.3.x too.

if you use appropriate naming for db handles, there should be no
confusion. i'd also suggest you take a look at Apache::DBI.

i don't know what framework you're using, or how you will segregate the
apps. it might be better to have them all running under one webserver,
or maybe you will need to start up a few of them. there are many
mod_perl application frameworks that may help you get up and running
more quickly.

i know HTML::Mason and CGI::Application pretty well, and i think either
could do what you want it to.

with mod_perl you can do pretty much anything you want, it's just how
much time do you have to spend programming to get it to work as you'd
like. with the frameworks, there's even less programming that you need
to do.

good luck.

-----Original Message-----
From: James. L [mailto:perlwle@yahoo.com]=20
Sent: Thursday, March 15, 2007 3:55 PM

having read modperl's doc and i am concerned about running multiple
unrelated mod_perl apps on one server, such as 2 or 3 medium Perl apps.
( issue like database handler pollution etc which i know little about )

Re: mod_perl implementation possibility

You should not develop anything new in mod_perl / Apache 1.3
That system is outdated and only receives bugfixes.

Use mp2/Apache2

the environment currently being mp1 is meaningless. mp apps often
work best on their on server, but that doesn't mean a physical
server: run apache2 on an alternate port like 8080, and proxy the
necessary port80 traffic to it.
i personally run different apaches on 8080,8081,8082 to maximize
memory usage.
in any event, so you can keep apache1 & apache2 on the same machine

// Jonathan Vanasco

| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| SyndiClick.com
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| 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
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -

Re: mod_perl implementation possibility

On Thu, 15 Mar 2007 12:54:37 -0700 (PDT)
"James. L" wrote:

> mod_perl 2 seems solve the problem with virtual host
> which will require us to adopt apache 2 and use
> virtual host.
>
> my understanding may be false but i would like to hear
> your point of view and help me figure out the problem
> we may have if we decide to use more Perl in our
> development.

I would definitely go with mod_perl 2.x for the reasons stated
previously.

Also, just wanted to point out that you can separate apps via
VirtualHosts in mp1 as well as mp2. There isn't anything
new about that ability in mp2.

I've got servers with probably 20+ different small/mid/large
sized apps in the same Apache without issue, both in mp1 and
mp2 scenarios. Largest app in that bunch is around 50k lines of
Perl.

With good coding practices it really shouldn't be an issue.

---------------------------------
Frank Wiles
http://www.wiles.org
---------------------------------

Re: mod_perl implementation possibility

> we are exploring the idea of writing medium to large
> Perl apps in the future which will require mod_perl.
> the current environment is apache 1.3. having read
> modperl's doc and i am concerned about running
> multiple unrelated mod_perl apps on one server, such
> as 2 or 3 medium Perl apps. ( issue like database
> handler pollution etc which i know little about )
>

The only place where you would have an issue with running multiple
applications within one server (even if distributed across virtual
servers) is where :
- you have a common module that is used by more than one application
- that module has the concept of a single set of configuration data
rather than a per-application set

Not very clear, so let me give an example.

If, for example, you were to have a module called My::Template, that is
used by 5 different applications.

My::Template stores the path to the templates in the package wide
variable $template_path.

As each application sets its own template_path, it overrides the setting
from the application before.

The ways to avoid this are:
* you pass the template path in to My::Template every time you call it

process_template ($template_path, $template_name, $data)

* you create a My::Template object which, amongst other things, has
the template path as a property

$t = My::Template->new();
$t->template_path($path);
$t->process_template($template,$data);

* for classes which inherit from My::Template, instead of using a
scalar $template_path, you use a hash, which has the class of the
calling object as the key, and that classes template path as the
value

package My::Template;

my %Template_Path;

sub template_path {
my $self = shift;
my $class = ref $self || $self;
if (@_) {
my $path = shift;
$Template_Path{$class} = $path};
}
return $Template_Path{$class}
}


Another example of things with global effects is the current working
directory. CWD is global, and thus you cannot rely on it staying the
same. The safest way to handle this is to just use absolute filenames.

hth

Clint

Re: mod_perl implementation possibility

--- Frank Wiles wrote:

> On Thu, 15 Mar 2007 12:54:37 -0700 (PDT)
> "James. L" wrote:
>
> > mod_perl 2 seems solve the problem with virtual
> host
> > which will require us to adopt apache 2 and use
> > virtual host.
> >
> > my understanding may be false but i would like to
> hear
> > your point of view and help me figure out the
> problem
> > we may have if we decide to use more Perl in our
> > development.
>
> I would definitely go with mod_perl 2.x for the
> reasons stated
> previously.
>
> Also, just wanted to point out that you can
> separate apps via
> VirtualHosts in mp1 as well as mp2. There isn't
> anything
> new about that ability in mp2.
>
> I've got servers with probably 20+ different
> small/mid/large
> sized apps in the same Apache without issue, both
> in mp1 and
> mp2 scenarios. Largest app in that bunch is
> around 50k lines of
> Perl.
>
> With good coding practices it really shouldn't be
> an issue.

any special setup for mod_perl 1 + apache 1 under
virtual host? it works but my impression is that it is
hard to setup and must be coded very carefully.

that's probably the reason why i rarely see mod_perl
offered in share dhosting environment.


> ---------------------------------
> Frank Wiles
> http://www.wiles.org
> ---------------------------------

James.



____________________________________________________________ ________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html

RE: mod_perl implementation possibility

--- John Saylor wrote:

> as far as running multiple unrelated perl apps using
> mod_perl- i think
> it happens every day! you just need to program them
> accordingly. also,
> you can use virtual hosts under apache 1.3.x too.
>
> if you use appropriate naming for db handles, there
> should be no
> confusion. i'd also suggest you take a look at
> Apache::DBI.

is that it? from another response, there are other
issues i need to be careful about.

> i don't know what framework you're using, or how you
> will segregate the
> apps. it might be better to have them all running
> under one webserver,
> or maybe you will need to start up a few of them.
> there are many
> mod_perl application frameworks that may help you
> get up and running
> more quickly.
>
> i know HTML::Mason and CGI::Application pretty well,
> and i think either
> could do what you want it to.

i think we will run multiple mod_perl apps in one or
more servers.

we are slowly adopting CGI::Application in current app
and one of the advantage of it is that, when the time
comes, i can just slam it to mod_perl and run without
any or minor changes, or i hope.

> with mod_perl you can do pretty much anything you
> want, it's just how
> much time do you have to spend programming to get it
> to work as you'd
> like. with the frameworks, there's even less
> programming that you need
> to do.
>
> good luck.
>
> -----Original Message-----
> From: James. L [mailto:perlwle@yahoo.com]
> Sent: Thursday, March 15, 2007 3:55 PM
>
> having read modperl's doc and i am concerned about
> running multiple
> unrelated mod_perl apps on one server, such as 2 or
> 3 medium Perl apps.
> ( issue like database handler pollution etc which i
> know little about )
>
>

thanks,

James.



____________________________________________________________ ________________________
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

Re: mod_perl implementation possibility

On Mar 16, 2007, at 11:55 AM, James. L wrote:

> any special setup for mod_perl 1 + apache 1 under
> virtual host? it works but my impression is that it is
> hard to setup and must be coded very carefully.
>
> that's probably the reason why i rarely see mod_perl
> offered in share dhosting environment.

no, mod_perl is just unsuitable for shared hosting by design. it has
nothing to do with virtual hosts.

a- mp caches code into apache. it can take *a lot* of ram.
there's no effective way to manage memory in these situations -- you
either preload everyone's stuff into apache at start, or apache takes
a performance hit each time a child reads code for the first time.
because apache children expire after x requests, in a shared
environment you'll get almost no speedup - and a potential
performance decrease.
b- as clinton noted previously, the way mod_perl handles namespaces
can cause overlap issues

As I said before, you're best off to just install apache2 and mp2 *in
addition to apache1*. you can keep all your apache1 stuff running as-
is on port 80. just run/configure apache2/mp2 to run on an alternate
port - like 8080 , and proxy the necessary requests to it via
mod_proxy on 80.


// Jonathan Vanasco

| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| SyndiClick.com
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| 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
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -

Re: mod_perl implementation possibility

On 3/16/07, James. L wrote:
> any special setup for mod_perl 1 + apache 1 under
> virtual host? it works but my impression is that it is
> hard to setup and must be coded very carefully.

It's not hard to setup, and it doesn't require any special coding
practices beyond any other long-running perl program. Since there is
only one interpreter running in each child process, you can't do crazy
things like load two different versions of the same module. If you
wanted to do that (say you want to have your staging code and your
production code), the easiest approach is to run multiple apaches.
There's a lot of documentation and suggestions about this in the docs
on perl.apache.org and in the mod_perl books.

> that's probably the reason why i rarely see mod_perl
> offered in share dhosting environment.

If you're looking for cheap hosting, try looking for one that offers
you your own virtual machine with full access. Those are pretty
inexpensive.

- Perrin

Re: mod_perl implementation possibility

--- Clinton Gormley wrote:

> > we are exploring the idea of writing medium to
> large
> > Perl apps in the future which will require
> mod_perl.
> > the current environment is apache 1.3. having
> read
> > modperl's doc and i am concerned about running
> > multiple unrelated mod_perl apps on one server,
> such
> > as 2 or 3 medium Perl apps. ( issue like database
> > handler pollution etc which i know little about )
> >
>
> The only place where you would have an issue with
> running multiple
> applications within one server (even if distributed
> across virtual
> servers) is where :
> - you have a common module that is used by more
> than one application
> - that module has the concept of a single set of
> configuration data
> rather than a per-application set
>
> Not very clear, so let me give an example.
>
> If, for example, you were to have a module called
> My::Template, that is
> used by 5 different applications.
>
> My::Template stores the path to the templates in the
> package wide
> variable $template_path.
>
> As each application sets its own template_path, it
> overrides the setting
> from the application before.
>
> The ways to avoid this are:
> * you pass the template path in to My::Template
> every time you call it
>
> process_template ($template_path,
> $template_name, $data)
>
> * you create a My::Template object which, amongst
> other things, has
> the template path as a property
>
> $t = My::Template->new();
> $t->template_path($path);
> $t->process_template($template,$data);
>
> * for classes which inherit from My::Template,
> instead of using a
> scalar $template_path, you use a hash, which has
> the class of the
> calling object as the key, and that classes
> template path as the
> value
>
> package My::Template;
>
> my %Template_Path;
>
> sub template_path {
> my $self = shift;
> my $class = ref $self || $self;
> if (@_) {
> my $path = shift;
> $Template_Path{$class} = $path};
> }
> return $Template_Path{$class}
> }
>
>
> Another example of things with global effects is the
> current working
> directory. CWD is global, and thus you cannot rely
> on it staying the
> same. The safest way to handle this is to just use
> absolute filenames.

thanks! I actually have an example of this. A module
for event logging purpose. the global variable is a
hash consists a set of default log flags corresponding
to log messages.

i can register a new flag/msg to the global variable
in my app and go on with the logging. a simplified
version :

package EventLogging;

my %EVENT_TYPES = ( log_in_ok => 'Login OK', .. );
sub add_event {
my ($self, $your_event) = @_;
while ( my ($k, $v) = each %$your_event ) {
$EVENT_TYPES{ $k } = $v;
}
}

use EventLogging;
my $elog = EventLogging->new()
$elog->add_event({...});

now under mod_perl with few apps sharing the same
module, what's the best way to solve this problem ?

mod_perl has an excellent document. but is there a
checklist kind of thing for running mod_perl in
environment like this? where can i read more about
this?

> hth
>
> Clint
>
>

thanks,

James.



____________________________________________________________ ________________________
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097

Re: mod_perl implementation possibility

> thanks! I actually have an example of this. A module
> for event logging purpose. the global variable is a
> hash consists a set of default log flags corresponding
> to log messages.
>
> i can register a new flag/msg to the global variable
> in my app and go on with the logging. a simplified
> version :
>
> package EventLogging;
>
> my %EVENT_TYPES = ( log_in_ok => 'Login OK', .. );
> sub add_event {
> my ($self, $your_event) = @_;
> while ( my ($k, $v) = each %$your_event ) {
> $EVENT_TYPES{ $k } = $v;
> }
> }
>
> use EventLogging;
> my $elog = EventLogging->new()
> $elog->add_event({...});
>
> now under mod_perl with few apps sharing the same
> module, what's the best way to solve this problem ?

Well, depends how you're using it.

1) If you create a new EventLogging instance at the beginning of your
application, which you continue to use throughout the application, then
store the added events in the object itself.

For instance: (I'm assuming that EventLogging->new returns a blessed
hashref rather than some other form of object)

sub add_event {
my $self = shift;
my ($name,$description) = @_;
$self->{_events}->{$name} = $description;
return $self->{_events} # or whatever
}

sub get_event {
my $self = shift;
my $name = shift;
die "Event '$name' doesn't exist"
unless exists $self->{_events}->{$name};
return $self->{_events}->{$name}
}


2) Maybe you don't want to keep an instance of EventLogging lying around
and you want to just use class methods to set the events at startup, and
then get a new event object whenever you want it.

Then you could subclass EventLogging for each application, eg:

package AppOne::EventLogging;

use base 'EventLogging';

package EventLogging;

my %Events;

sub get_event {
my $self = shift;
my $class = ref $self || $self;
my $name = shift;
die "Event '$name' doesn't exist"
unless exists $Events{$class}->{$name};
return $Events{$class}->{$name}
}


---------------------------------
EventLogging->add_event($name,$description);

my $event = EventLogging->new();
my $description = $event->($name);


>
> mod_perl has an excellent document. but is there a
> checklist kind of thing for running mod_perl in
> environment like this? where can i read more about
> this?

Not that I know of, but if you just think of mod_perl being one big
application, with multiple entry points. So just avoid doing anything
that would affect the running of other parts of The Program.

It's the same way you program now. You're aware of the shared parts of
your code. You know that if you change the current working directory in
sub 1, that it's still going to be changed when sub 2 is called. It's
the same.

One other thing to remember is that you need to be careful at startup
with anything that opens a process, or with DBI handles. If, during
startup, you open a connection to the database (or to memcached for
instance), you will have a problem if you try to continue using that
connection. Apache starts the parent process, then forks and starts all
the children that do the work. If the children are using an old
connection/db handler/etc, they will be trying to share it, and that
don't work! Either delay your connections until after startup, or make
sure that you're not reusing the old connections.

Apache::DBI will help you here.

However, you SHOULD load your modules and setup your configuration
before forking, because that way each child doesn't have to do it, and
all that data is shared, so you save a lot on memory.

Clint
>
> > hth
> >
> > Clint
> >
> >
>
> thanks,
>
> James.
>
>
>
> ____________________________________________________________ ________________________
> Finding fabulous fares is fun.
> Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
> http://farechase.yahoo.com/promo-generic-14795097

Re: mod_perl implementation possibility

On Fri, 16 Mar 2007 18:20:28 +0100
Clinton Gormley wrote:

> > mod_perl has an excellent document. but is there a
> > checklist kind of thing for running mod_perl in
> > environment like this? where can i read more about
> > this?
>
> Not that I know of, but if you just think of mod_perl being one big
> application, with multiple entry points. So just avoid doing anything
> that would affect the running of other parts of The Program.
>
> It's the same way you program now. You're aware of the shared parts
> of your code. You know that if you change the current working
> directory in sub 1, that it's still going to be changed when sub 2 is
> called. It's the same.
>
> One other thing to remember is that you need to be careful at startup
> with anything that opens a process, or with DBI handles. If, during
> startup, you open a connection to the database (or to memcached for
> instance), you will have a problem if you try to continue using that
> connection. Apache starts the parent process, then forks and starts
> all the children that do the work. If the children are using an old
> connection/db handler/etc, they will be trying to share it, and that
> don't work! Either delay your connections until after startup, or
> make sure that you're not reusing the old connections.
>
> Apache::DBI will help you here.
>
> However, you SHOULD load your modules and setup your configuration
> before forking, because that way each child doesn't have to do it, and
> all that data is shared, so you save a lot on memory.

+1, I think that's a great description of the major caveats to coding
in mod_perl.

---------------------------------
Frank Wiles
http://www.wiles.org
---------------------------------