in reply to Getting mod_perl to actually 'activate'..

Stop worrying. If $ENV{MOD_PERL} is defined, you are running under mod_perl, not CGI. However, I'd suggest you upgrade your mod_perl since the one you have there is buggy and about 4 years old.
  • Comment on Re: Getting mod_perl to actually 'activate'..

Replies are listed 'Best First'.
Re^2: Getting mod_perl to actually 'activate'..
by MashMashy (Sexton) on Feb 16, 2009 at 17:25 UTC
    Thanks! However, if that's true, how come code that looks like this:
    #!/usr/bin/perl sub name_of_sub_1{ return 1; } sub name_of_sub_2{ return 1; } ... sub name_of_sub_100{ return 1; } ##actual code here exit;
    Still takes a long time to run every instance that the code is called from an http request? Wouldn't all those subroutines just get loaded into memory once, drastically shortening the runtime?

    (Thanks, by the way for all your help!)
      The code you're showing here will take no time at all to run under mod_perl since it will be compiled into constants on the first request. However, keep in mind that we're talking about the first request per process, so you may hit a different child process each time on your first few clicks. An easy way to tell is it to put something like this in your script:
      our $counter; $counter++; print $counter;
        Okay, this is the meat of the problem, then. Rather than make a new thread, mind if I talk about it here?

        Here are the questions I'm getting hug up on, it seems:
        1. how often will these be 'recompiled'?
        2. how can I tell when all the 'child processes' are good to go (i.e. all preloaded)
        3. should I expect these to re-"precompile" on me? This code is being hit by a great many different users once a day - will it compile for each user, or only until all the 'child processes' are good to go?
        3b. am I thinking of 'child processes' incorrectly here?

        Again, Thanks so much - you are turning a light on in a dark room. :)