perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [mp2] Benchmarks comparing mp2 vs. mp1
Date Wed, 07 May 2003 01:11:50 GMT
Josh Chamas wrote:
> Hey,
> 
> I have run a series of Hello World benchmarks comparing mp2 vs mp1.

[...]

> Comparing the 2nd and 3rd data sets is interesting, as this can 
> highlight the differences
> between mp2 + threaded perl + prefork apache vs. mp2 + threaded perl + 
> worker apache mpm.
> The benchmark configuration for prefork apache is 20 MaxClients, but 
> with worker mpm apache
> + mp2 it is:
> 
>   MaxClients 20
>   ServerLimit 5
>   ThreadsPerChild 4
>   PerlInterpMax 1
> 
> The point of this last config is to simulate what would be production 
> configuration ratios,
> while running perl in a fairly thread safe way with just one perl 
> interpreter per process,
> to avoid possible non-thread safe C library issues. 

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.

> This worker mpm 
> config should have
> the advantage that 3/4 of the threads per process would be able to serve 
> non-mod_perl
> requests, leaving one perl interpreter per process for mod_perl.  I see 
> this
> ultimately as being one type of performance config for mp2 + worker mpm, 
> where this might
> scale up to 400 MaxClients, 100 Server Limit, 4 ThreadsPerChild, 1 
> PerlInterpMax.
> The final effect of this would be to scale back mod_perl memory usage, 
> while keeping
> MaxClients high, and might do away with the need for a dual httpd 
> performance config.

You will benefit much more from using fewer processes with each having as many 
perl interepreters as needed with worker mpm, because you will get a shared 
opcode tree, which will save much more memory than you do with COW 
(copy-on-write with forking). Morever, this sharing is constant, it doesn't 
get unshared after a certain time. Ideally, for maximum sharing, you want only 
one process. However this is a bit error-prone if you get any segfaults.

The second point, is that the interpreters are put back into the head of the 
stack, so you get the maximum code re-use and if you have a few spare 
interepreters that were never used, they use almost no extra memory, since 
their opcode tree is shared.

Consider having a benchmark where you have let's say 2-3 procs with 
PerlInterpMax 10-20.

Overall it's good to see that an unoptimized mp2 does a pretty good job. 
Thanks for the benchmark.

Also may I suggest that it's easier to compare things when the columns contain 
data from different setups. e.g. comparing only request per secs.

One more point to remember about the threaded mpms, that the performance may 
vary wildly from one platform to another, as on certain platforms the threads 
implementation is slow. And on certain platforms threads scale better on SMP 
machines, while on others this might not be the case.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Mime
View raw message