[cgiapp] How to lazy-load runmodes

[Joshua Miller]

On Mon, May 23, 2011 at 11:15 PM, gvim <gvimrc at gmail.com> wrote:

> If I have a collection of, say, 15 fairly lengthy Perl scripts and I
> convert them into a CGI::Application app with 15 runmodes isn't there a huge
> startup penalty since my app must now load the code for all 15 runmodes
> prior to dispatch? Is there a way to lazy-load my runmodes? Although I have
> each one contained in a separate module I still have to 'use' all of them at
> once when the app starts.
>

Disclaimer - I haven't touched CGI::Application in over a year, and my last
go at it was to convert the product I'm currently supporting (~750,000 lines
of perl) to C:A, which never happened (got the framework in place, and had
disagreements internally on the template system, and the project went stale
- very sad). Anyway...

"isn't there a huge startup penalty..."
Not if you're using FastCGI, PSGI + something like FastCGI or mod_perl,
mod_perl, Starman or any other persistent perl thing. In those cases, it
loads and compiles once, and subsequent hits go to the compiled perl
bytecode (more or less). It's actually better and faster to have everything
loaded at first in these, so that memory is shared (COW for mod_perl under
linux). Under plain old bare-bones CGI, yes, there is a startup penalty on
every hit.

"Is there a way to lazy-load my runmodes?"
Yes. The exact details of that will depend on how you implement things, and
others here may have some recommendations. Lazy-loading modules will end up
breaking down to the following at some point in the code:

unless (eval "require $modulename") {
    # handle the error. $@ will contain the error message.
}


In nearly all cases, the lazy loading won't be needed. If you're stuck with
running pure CGI, then it'll help some, but you'll get a lot more bang for
your buck by getting a provider or service running that supports mod_perl,
FastCGI, etc. Or, if you have a large or complex codebase, you might be
splitting off groups of functionality to different server clusters, and
those only need to have the modules loaded that are relevant to them... but
that's certainly not the case here.


Sorry... you were probably hoping for a drop in solution tailored to C:A
(and there may be one, but I don't know offhand) and I didn't help there,
and this is probably more info than you needed to hear.

If you have some info on what environment you're working with, I'm sure
someone can offer up some recommendations on a suitable persistent perl
server. Plack seems to be getting a fair bit of attention these days...
might want to start there (they have a long list of servers right on the
front page: http://plackperl.org/).

Hope that helps some,
--
Josh I.