[cgiapp] How to lazy-load runmodes

Michael Peters mpeters at plusthree.com
Tue May 24 09:18:59 EDT 2011


On 05/24/2011 07:34 AM, gvim wrote:

> Whilst a FastCGI solution improves startup time it doesn't address the memory footprint. I'm comparing deploying an app with CGI::Application vs. CGI with separate Perl scripts on a VM with a modest amount of mempory. From the what I'm learning about CGI::Application it seems that the memory footprint will skyrocket if your codebase has, say, 15 Perl scripts each containing over 300 lines of code as you now have 15 x 300 lines of code running instead of 300, no?

You're concerning yourself with irrelevant details until you know it's a 
problem. As Ron Savage pointed out earlier in the thread, if you split 
your run modes out into specific modules and then used C::A::Dispatch to 
dispatch between them then you'd basically have lazy loading.

But the key here is that you're worrying about memory usage before you 
know it's a problem. Perl abstracts a lot of the details about memory is 
used from you and any guesses you take about how much things will be 
will likely be wrong. 300 lines of code is nothing, memory wise. Data 
takes up a lot more space than code.

So my advice, write the application in a way that is the most 
maintainable and easy to adapt for the developers. Then do some 
profiling and find out if you are within your memory parameters and then 
(and only then, after you know it's a problem) do some memory tunings.

BTW, just some free advice from my experience: having a persistent 
(mod_perl, FastCGI, Starman, etc) environment will actually save you 
memory on linux. Forked processes will do copy-on-write (COW) memory so 
they will physically share the same memory even though logically they 
have their own memory space.

-- 
Michael Peters
Plus Three, LP


More information about the cgiapp mailing list