Re: Performance advantages to one large, -or many small mod_perl program?
Thanks, and pardon the newbie question, but by "modules" are you referring to ".pm" files placed in the perl lib directory? OR to some other mod_perl type file/cofiguration? Keith The best technique is to write all your code using modules and having only a few lines of code in the scripts.
Re: Performance advantages to one large, -or many small mod_perl program?
and pardon the newbie question, but by "modules" are you referring to ".pm" files placed in the perl lib directory? OR to some other mod_perl type file/cofiguration? Keith The best technique is to write all your code using modules and having only a few lines of code in the scripts. I meant the Perl module, not Apache's mod_foo. % perldoc -q module [snipped] =head1 Found in /usr/lib/perl5/5.00503/pod/perlfaq7.pod =head2 How do I create a module? A module is a package that lives in a file of the same name. For example, the Hello::There module would live in Hello/There.pm. For details, read Lperlmod. You'll also find LExporter helpful. If you're writing a C or mixed-language module with both C and Perl, then you should study Lperlxstut. [snipped] ___ Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
Re: Performance advantages to one large, -or many small mod_perl program?
A module is a package that lives in a file of the same name. For example, the Hello::There module would live in Hello/There.pm. For details, read Lperlmod. You'll also find LExporter helpful. If you're writing a C or mixed-language module with both C and Perl, then you should study Lperlxstut. [snipped] Is there any way to make mod_perl reload modified modules in some directories but not check at all in others? I'd like to avoid the overhead of stat'ing the stable modules every time but still automatically pick up changes in things under development. We have discussed this many times before. The conclusion was to modify the StatINC module to make its behavior configuration more flexible, rather than just On|Off options. You are very welcome to modify this module and add it the missing features so you can tell for example: PerlSetEnv StatINCDomain /foo /bar and only these directories will be watched after. Before you start implementing this feature, please grab the latest copy from the CVS or CVS snapshot http://perl.apache.org/from-cvs/modperl . Thanks a lot for this invaluable contribution! P.S. also take a look at somewhat different solution provided by Randal, see his Stonehenge::Reload at http://www.mail-archive.com/modperl@apache.org/msg03068.html P.S.S - Ha, while looking for Randal's modules at CPAN (they aren't there! Randal?) I've found Module::Reload module written by Doug and Joshua Pritikin back in 1998, you might find it useful too! ___ Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
Re: Performance advantages to one large, -or many small mod_perl program?
According to Ask Bjoern Hansen: Is there any way to make mod_perl reload modified modules in some directories but not check at all in others? I'd like to avoid the overhead of stat'ing the stable modules every time but still automatically pick up changes in things under development. I made that an option for Apache::StatINC. I've made it and lost it a few times, but some day I will get it done, tested and commited. :) I was going to make the trigger on the module name though. Hmn. Maybe look at the directory too would make sense. We have a lot of local modules, some used both by mod_perl and normal scripts. To make it easier to keep them updated across machines and avoid having to 'use lib' everywhere, I put a symlink under the normal site_perl to a directory that is physically with other web related work. So in this case it really is a component of the module name (mapped by perl to the symlinked directory...) that I would want as the trigger, but it would be equally likely that someone would 'use lib' to pick up their local development. I'd put a lot more programming into the modules and out of the web scripts if modifications were always picked up automatically without having to stat the modules that rarely change. Les Mikesell [EMAIL PROTECTED]
Re: Performance advantages to one large, -or many small mod_perl program?
Is there any performance advantage (speed, memory consumption) to creating a single, large, mod_perl program that can handle various types of "requests" for database data (fetchUserData fetchPaymentData, fetchSubscriptionData) as opposed to many small mod_perl scripts each related to a particular type of request? Keith, I think your question can be as easily changed to: "Should I use many small scripts or just a few having all the code inside or in modules?". There is almost no difference, since all the code is compiled once and cached since than. The best technique is to write all your code using modules and having only a few lines of code in the scripts. The only possible overhead with all-in-one approach is a need to pass the control variables so the code with know what functions to call. But this overhead is negligible. The only other thing is that you will have to change the URLs to use these control variables. From my experince, the maintance of big multi-functional applications is much easier when you don't mess with scripts, but centralize all the code in modules. It also make you write better code since you will have less code duplications. Probably there are more benefits. The only benefit of using many small scripts that I can see, is if there are some scripts that are almost never get used. So with small scripts you probably can save a few MBytes... Taken that there is no difference in time between loading a few big modules and a single small script (they all are cached), this question scales up to the general question of sw design which others will probably answer better than me :) ___ Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
