Hello,
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
> 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
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 s
> 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
According to Stas Bekman:
> 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 L. You'll also find L helpful. If
> you're writing a C or mixed-language module with both C and Perl, then
> you sh
> > 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 L. You'll also find L helpful. If
> > you're writing a C or mixed-language module with both C and Perl, then
> > you should study L.
> >
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 develop
