Be Careful with Symbolic Links

 

As you know Apache::Registry caches the scripts in the packages whose
names are constructed by scripts' URI. If you have the same script that
can be reached by different URIs, which is possible if you have used
symbolic links, you will get the same script stored twice in the memory.

You could do no worse than read Stas Bekman's articles on Perl.com.


--
ajt

Is that really what you meant to say?

;")

--Bob Niederman, http://bob-n.com

If you use a module with two different pathes ( usiing symlinks for instance) does mod_perl knows it's the same code and avoids compiling it twice ?

It sounds to me like you need to read more about mod_perl.

update: consider this

use strict;
use lib 'blinky';
use Data::Dumper;
warn Dumper( \%INC, \@INC );

__END__
$VAR1 = {
          'Carp.pm' => 'C:/Perl/lib/Carp.pm',
          'Exporter.pm' => 'C:/Perl/lib/Exporter.pm',
          'XSLoader.pm' => 'C:/Perl/lib/XSLoader.pm',
          'strict.pm' => 'C:/Perl/lib/strict.pm',
          'warnings/register.pm' => 'C:/Perl/lib/warnings/register.pm'
+,
          'Config.pm' => 'C:/Perl/lib/Config.pm',
          'warnings.pm' => 'C:/Perl/lib/warnings.pm',
          'lib.pm' => 'C:/Perl/lib/lib.pm',
          'overload.pm' => 'C:/Perl/lib/overload.pm',
          'Data/Dumper.pm' => 'C:/Perl/lib/Data/Dumper.pm'
        };
$VAR2 = [
          'blinky',
          'C:/Perl/lib',
          'C:/Perl/site/lib',
          '.'
        ];
[download]

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"

I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).

** The third rule of perl club is a statement of fact: pod is sexy.

I think you really only want to load a different config file depending on the virtual host being requested. You shouldn't need to do anything fancy with your modules just 'use' then in your scripts/handlers and load the appropriate config file.

If you have some modules which are similarly named but customised for each virtual host, then you will need to look at fixing this by either merging or renaming them and relagating any differences to your config file.

Configuration Files: Writing, Dynamically Updating and Reloading <- a good read

Update:
If anybody has a solution to minimize the amount of memory taken when using the same set of modules from 2 vhosts, I'd be very glad.

Are you running cgi scripts through registry, or mod_perl handlers?

Have you gotten to this in the tuning docs..? Preloading Registry Scripts at Server Startup

cheers,

J

I read the whole tuning stuff several times but it's very dense, I guess I'll have to re read it many times before really understanding the "Whole Big Picture of Things"

Ok to make things clearer:

I use only MethodHandlers.
My modules reside in a structure like this: Projet1/handler1.pm
Projet1/handler2.pm
And I have a
lib/Project1Config1/param.pm
lib/Project1Config2/param.pm

Each vHost uses the same module, except for the config file
And I'm asking myself a lot of silly question on wether it is efficient or not, wheter I could find a way to organize things to save up memory
It seems that the answer is no, exept if I preload the handler modules at startup, but I have to be sure that the right vHost gets the right config file, and that things don't mess up along the way.

I'll be reading your links right away, thanx :)

Perhaps I've misunderstood your question, but perhaps it might work if you created instances of the generic handler class, with the configuration file passed as an argument to the constructor. Then you'd only be use the generic class once, and creating a differently configured handler instance to do the work for each vhost. This reworking should be fairly painless if you're already using method handlers. So, for each host you might have something like the following in startup.pl:

# startup1.pl
use GenericModule;

$My::VirtualHost_1_Handler = GenericModule->new(
    'config' => '/path/to/lib/Project1Config1/param.pm'
);
[download]

Then in your VirtualHost section:

PerlRequire '/path/to/startup1.pl'
SetHandler perl-script
PerlHandler $My::VirtualHost_1_Handler->handle
[download]

Then all you'd need to add would be some code to your generic class's new method that reads in the configuration variables and sets them as attributes of the specific instances. Each virtual host could then have one or more separate handler object instances, each with its own private configuration variables held as object attributes.

HTH
ViceRaid