[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