Applying a simple trace to modperl_interp.c:
+ MP_TRACE_i(MP_FUNC, "perl_clone start\n"); interp->perl = perl_clone(perl, clone_flags); + MP_TRACE_i(MP_FUNC, "perl_clone end\n");
easily shows that perl_clone() is the one that takes an impractical amount of time to complete.
Where does this bring us? When a new request is coming in and all interpreters are busy and the pool quota is not full, a new interepreter will be cloned. And your request will be served in 6-10 secs instead of 50msecs. Now imagine a busy webserver with no spare CPU cycles, perl_clone may take 20 secs and more.
I certainly don't disagree with you that this is not ideal and we ought to improve it if we can.
The problem is that it's not under our control. The slow part is perl_clone, which is a perl API. It's slow because it takes time to clone all the non-mutable data. Nick has been working on COW (Copy-On-Write), but from his reports it doesn't seem to give much speedup if at all.
however, what this means to me is that you need to tweak and tune a threaded mpm - namely PerlInterpMinSpare - just like you do prefork if you don't want your application to suffer. I know lots of people were hoping that the threaded mpms would improve performance by mere virtue of the reduced process size, but I guess there is a trade-off in that.
Yup. The only way I see it working well is by using dedicated pools for each separate application which uses its own modules, not overlapping with other apps.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
