3

I did a little searching first but haven't found a satisfactory answer yet (my apologies if this is a repeat question -- or worse, a stupid question)...

Do dynamically loaded Perl modules such as those included with the answer to this question (relevant code replicated below) get properly cached by mod_perl for future usage?

my $module = 'My::Module';

eval {
    (my $file = $module) =~ s|::|/|g;
    require $file . '.pm';
    $module->import();
    1;
} or do {
    my $error = $@;
    # ...
};

In the above example, will "My::Module" be cached by mod_perl after this invocation for future usage if a subroutine similarly tries to require it in the future (at least in whatever manner mod_perl generally uses for package caching)?

Hopefully that question is somewhat clear, please let me know if any clarification is needed. Thanks.

Community
  • 1
  • 1
StudyOfCrying
  • 530
  • 3
  • 9

1 Answers1

3

Yes, it will be cached by perl itself. (mod_perl's task concerning this topic is only to translate scripts into cachable packages and take care to keep a Perl running the whole time instead of exiting when a response is finished.)

You must understand, though, how this plays out in the various httpd MPMs. Mind that processes have independent %INC. With prefork, the following example program will need to dynamically load the module for each fresh child. This means the first couple of requests will be slower than average because they are handled round-robin. The module is cached until the child exits because it has reached its max requests threshold, then each new child has to load again.

package Foo;
use Apache2::Const -compile => qw(OK);
use Apache2::RequestIO qw();
use Apache2::RequestRec qw();
use Data::Dumper qw(Dumper);

sub handler {
    my ($r) = @_;

    $r->content_type('text/plain');
    $Data::Dumper::Sortkeys = 1;
    $r->print(Dumper \%INC);

    my $module = 'Template';
    eval {
        (my $file = $module) =~ s|::|/|g;
        require $file . '.pm';
        $module->import();
        1;
    } or die $@;

    $r->print(Dumper \%INC);
    return Apache2::Const::OK;
}

1;

It is generally recommended to optimise for performance by loading any module you could possibly need already at server start-up before forking takes place. The server hardware should have enough memory to make the module lazy-loading trade-off unnecessary.

daxim
  • 39,270
  • 4
  • 65
  • 132
  • Thank you very much for the insightful answer. This is exactly what I was looking for. Along similar lines, is there any good reason (other than Apache startup time) to _not_ preload all modules that are likely to be used during the life of any arbitrary child process? Thanks again, very helpful answer. – StudyOfCrying Feb 09 '12 at 15:56
  • One other reason I can think of: attempting to load modules that are mutually incompatible. Did not happen to me personally yet, and usually there exists some better work-around for those kind of problems. – daxim Feb 09 '12 at 18:39