Thank you, Mark & Perrin for your help!
> > Is there a way to manipulate @INC without having to use a startup.pl in>
> > Sure. For example, PERL5LIB.
Yes, sure. Sorry,my question wasn't correctly formulated.
Below is closer to what I was looking for and should have expressed.
> Regarding relative paths, I wouldn't recommend putting your perl> libraries
> inside of DOCUMENT_ROOT if you can avoid it.
In fact, in our staging environment libraries are working copies from
subversion,
hosted one folder above the domain folders with all the vhosts
and we use symlink that point to them in the cgi-bin.
it's perhaps a strange way of doing things (and if there's better, i'll take!!)
but we want to assume the most hostile environment
possible where we cannot do what we want, with the server and with perl (as it
does happen with some clients).
so in case of a contrived,restricted environment, we can just plug the entire
framework and have it works.
If we can change things for our best and the best of our client, we will
accomodate accordingly.
this is a compromise between SA/maintainability/flexibility and hassle^^;
> If you have to use relative paths, you want something like what Mark> Hedges
> suggested. That should work for ModPerl::PerlRun, where your> code is
> compiled every time. For ModPerl::Registry, you'd need to do> something like
> this:> > use FindBin;> unshift @INC, "$FindBin::Bin/../lib";> > Unlike "use
> lib", the unshift will run every time in Registry. Also,> if you use
> RegistryPrefork you won't need FindBin at all. You can> just use '../lib'.
I am using FindBin and added the FindBin::again() as recommanded
in hope to switch to ModPerl::RegistryPrefork soon.
I am using both use lib and unshift @INC but still, for some reasons,
even with ModPerl::PerlRunPrefork got some pages that could not load
and in the log, it was always due to a lib that couldn't be found.
If I reload the page, it works, If I reload again sometimes it won't.
Adding the startup.pl, get rid of this behavior.
But I will change all use lib into unshift @INC and see how it behaves.
I have to say that I do not really understand how mod_perl behaves regarding
the @INC manipulation.
> > I've tried also ModPerl::RegistryPrefork but got some tremendous blank
> > pages> > that leaved no log at all.> > I have absolutely no clue on how to
> > debug this ??> - Double-check the log file
Nothing there.> - Add some warn statements to see how far it gets.
I was putting print statement, but you're right should switch to warn!!
as for the print statements, it seems that the index.pl print statements were
executed
but none of the print statements in the loaded module. so I assumed that the
module wasn't loaded
but do not understand sometimes it is, sometimes it is not.
> - Examine the communication with the client through a proxy or Firefox plugin.
I've checked it thru firebug but is there a better plugin?
> I think that ModPerl::RegistryPrefork is ultimately where you want to> be,
> because it will be faster.
indeed!!!
I guess i will have to deal with some circular references lurking here and
there, sloppy old code
needing rewrites,etc
but this should boost the app so I definitely aim at switching to
ModPerl::RegistryPrefork!
I have to say that switching to ModPerl::PerlRunPrefork allowed me to improve
the performance in a amasing way!
Well, i have checked the performance with Apache Benchmark (ab n 100 c 5,etc)
and got a boost of about 20 times the cgi version when the simulated traffic is
high!!
Still, the ratio is very low but that is a real improvement and am really
looking forward to it!
(this is true for pages that were cached with Cache::Cache but required perl to
be executed in some way)
Thank you very much for your fast reply !
_________________________________________________________________
5GBのオンラインファイル保存サービス。Hotmailでファイル共有もできる！
http://clk.atdmt.com/GBL/go/msnjpqjl0090000077gbl/direct/01/
