On Tue, May 24, 2011 at 9:18 AM, Michael Peters <mpet...@plusthree.com>wrote:
> 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. > > Completely agree and second this. If you have a choice of FastCGI or CGI, just go FastCGI. If you're concerned about the differences in memory usage and such, you're free to benchmark them, but I can assure you that, under any load at all, FastCGI can serve more pages using less memory and cpu time. In my experience, mod_perl has been at least 10 times faster than CGI in overall response handling time. Couple that with the COW memory savings, and there's no going wrong here (though, with just 4500 lines of code, that's not much to save... you will save on the other libs that get dragged in). FYI, 300 lines of 72 characters times 15 == a file of 343 KB. If your env is more limited than that, then you should probably be looking at C or assembly :-) The libs you use from your CGI script will pull in far more than that. As an example: $ expr 300 \* 15 4500 $ wc -l /usr/share/perl/5.10/CGI.pm 7885 /usr/share/perl/5.10/CGI.pm -- 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/ ## ## ## ################################################################
