On Mon, May 23, 2011 at 11:15 PM, gvim <gvi...@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. ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################