We had been using Option 1 for a long time & we had absolutely no problems (with mod_perl-1.19/Apache-1.3.14/Perl-5.005). However on upgrading to mod_perl-1.26, we were getting hell lot of errors. I have tracked this to a bug in perl_util.c & on fixing this PerlFreshRestart works w/o any problems. I have posted this details 2/3 weeks back but haven't got any reply.
I had to go for option 1, since I was not sure about DSO & StatINC does stats() for every request that comes in - not too good. (even with a touchfile, it has to do stat() !) Sreeji --- Gordon Henriksen <[EMAIL PROTECTED]> wrote: > I'm looking at how to best avoid downtime during a > code upgrade, as we often > do spot releases of critical code fixes and we're > getting to the usage level > that I don't want to interrupt service to deploy > that code. At the same > time, I want to avoid running 200 stat()'s per > request for all of the loaded > modules. > > We're presently running in this configuration: > > Apache 1.3.22 > static mod_perl 1.26 > Apache::StatINC <--Want to get rid of it. > PerlFreshRestart OFF > > I see three options open to me: > > 1. static mod_perl w/ PerlFreshRestart > Reloads %INC. > downside: Heresay claims historical > instablity. > > 2. dynamic mod_perl > Tears down & cleans up Perl interpreter on > graceful restart. > downside: Heresay claims historical > instablity. > > 3. static mod_perl w/ Apache::StatInc > Runs many stat()'s per request. > downside: Runs many stat()'s per request. > > Aside from the historical instability, the second > option strikes me as the > cleanest and most robust. How has the current > stability of these mechanisms? > Is it enterprise-worthy? I'm variously running on > RedHat Linux 7.0 and 7.1. > > -- > > Gordon Henriksen > IT & Engineering > ICLUBcentral Inc. > [EMAIL PROTECTED] > __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
