perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [mp2] Benchmarks comparing mp2 vs. mp1
Date Wed, 07 May 2003 02:33:45 GMT
Josh Chamas wrote:
> Stas Bekman wrote:
>> Josh Chamas wrote:
>>> Stas Bekman wrote:
>>>> If you know of such a problem, either solve it or use the preforked 
>>>> MPM if you can. Using worker mpm with only one perl interpreter per 
>>>> thread, will be definitely slower than using a prefork mpm. Of 
>>>> course platforms like winFU have no choice but using their winnt mpm.
>>> What would be slower about this?  Let's say in the given config with
>>> 20 max clients, 5 processes, 4 threads each, and 1 perl interp each,
>>> should not 4 CPUs be able to run concurrently on such a benchmark?
>>> How would increasing the number of perl interpreters hurt this,
>>> are there some serializing issues that are particularly bad with
>>> mp2 and worker mpm ?  Is it just the threaded per penalty that makes
>>> this slower ( apparently threaded perl has a general 10-20% 
>>> performance hit
>>> from other benchmarks I've seen ).
>> Yes, enabling threads in perl and compiling mod_perl with it makes 
>> mod_perl slower if you don't use the benefit of the threaded 
>> environment, which is the case if you use only one perl interpreter 
>> per process. You both use more memory because more information needs 
>> to be 
> Thanks for the clarification.  I believe there can be an advantage to
> having the one perl intepreter per process model in worker mpm mode,
> that being namely to increase MaxClients capacity, which is a bane
> on standard mod_perl 1.x setups, such that we need to go to dual httpd
> or proxy/mod_perl httpd setups.  So, at this cost of some speed / CPU hit,
> doesn't a setup of 1 perl interpreter per process with many threads
> make sense if the bottleneck is the MaxClients / memory capacity,
> where a web site is being servied with non-mod_perl type requests
> that can be made concurrent to the mod_perl interpreter doing its thing?
> This would be to solve the "many users / slow modem" problem we often
> talk about with mp1.
> I was actually thinking about upgrading to such a config, to increase
> that MaxClients capacity, but not worrying so much about perl CPAN module,
> and c lib threading issues, yet take advantage of the threaded model
> for things like static images...
> Am I crazy to think this way? :)

Oh, you are talking the memory limiting tools, which won't quite work as is 
with threaded mpms.

Yes, in such a case you do get to use the same memory limiting tools under 
mp2/worker mpm and don't need a dual-httpd setup at the same time, since the 
perl interpreter won't be used for non-mod_perl requests. So I suppose that as 
of this moment this is probably a good compromise if the performance 
differences are negligible.

I think that once we figure out how to port those process based memory 
limiting tools to use with threads, than you can use this setup with only 1-2 
procs. This is another challenging area for development. We have discussed it 
a bit, and the early conclusion was that we will need to hook into the 
function that puts the interpreter back to the free queue, and have the logic 
to kill that interpreter if too much memory is used. Also remember that we may 
have a garbage collector thread, which will do that work for you.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message