in reply to how mod_perl finds if code has already been compiled

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

  • Comment on Re: how mod_perl finds if code has already been compiled

Replies are listed 'Best First'.
Re: Re: how mod_perl finds if code has already been compiled
by Sihal (Pilgrim) on Jun 16, 2003 at 14:52 UTC
    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 :)
[reply]

      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

[reply]
[d/l]
[select]
        This would be a very good solution indeed if my module was object oriented...
        I found some stuff about why what I wanted to do isn't possible on : Name Collision of Modules and libs
        A very interesting reading for us mod_perl users.
        Now I think i will use a method based on the previous link: Config Files, using a hash with a key for each vHost.
[reply]

In Section Seekers of Perl Wisdom