You are viewing a plain text version of this content. The canonical link for it is here.
Posted to asp@perl.apache.org by Josh Chamas <jo...@chamas.com> on 2003/05/06 21:38:09 UTC
[mp2] Benchmarks comparing mp2 vs. mp1
Hey,
I have run a series of Hello World benchmarks comparing mp2 vs mp1.
The first data set is mp1 with perl 5.80 no threads, apache 1 prefork.
The second data set is mp2 with perl 5.80 no threads, apache 2 with prefork mpm.
The third data set is mp2 with perl 5.80 with threads, apache 2 with worker mpm
See end of mail for benchmarks data...
=== BEGIN ANALYSIS...
What I found interesting when comparing prefork mp1 to prefork mp2, no threads perl,
overall the raw mod_perl handlers got significantly faster, the application environments
like Template Toolkit & HTML::Template run with mod_perl handler and using Apache::compat
were about the same speed or a little faster, and Apache::ASP having already been optimized
for mod_perl 2 was significantly slower by about 20%. Something about how Apache::ASP
is using the new mod_perl 2 API might be causing this and warrants further investigation.
Another point comparing the first 2 data sets is the consistant increased memory usage,
even for Apache::ASP 2.55 ( my dev version ) which loads all mp2 modules explicitly now,
and does not use Apache::compat. The rest might be accounted for as they are using
Apache::compat, however, I believe we will find that even once Apache::compat loading
is done away with, there will still be a few extra meg memory in comparisons to use mp2,
and currently each is showing 4-6M increased memory usage.
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. 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.
This worker mpm configuration effect is verified in the 2nd vs. 3rd benchmarks, where
the 3rd worker mpm configuration shows reduced memory usage by 20-25% for larger
web applications like Template Toolkit and Apache::ASP, but with a trade off of a 10-20%
speed hit. However, the lighter mod_perl handlers showed both a reduced speed AND
increased memory usage. This might be because of extra per PerlInterp allocatation overhead
( might this be a clone of a parent perl interpreter? ), and since the prefork mpm
mod_perl handler had such a small memory footprint, the savings were not realized.
This is just speculative, as I have little insight into the mp2 worker mpm architecture.
=== END ANALYSIS
The benchmarks were run using this tool:
http://chamas.com/bench/dist/Apache-Bench-HelloWorld-1.04.tar.gz
and the data came from this command which specified 3 separate apache
builds on my system ...
./bench.pl --dso --httpd /usr/local/apache/bin/httpd --time=15 '^(Apache::ASP.*mod_perl|mod_perl handler|HTML::Template mod_per
l|Template Toolkit mod_perl) (Hello|2000)$'; ./bench.pl --dso --httpd /usr/local/apache2/bin/httpd --time=15 '^(Apache::ASP.*mod_perl|mod_perl ha
ndler|HTML::Template mod_perl|Template Toolkit mod_perl) (Hello|2000)$'; ./bench.pl --dso --httpd /usr/local/apache2w/bin/httpd --time=15 '^(Apac
he::ASP.*mod_perl|mod_perl handler|HTML::Template mod_perl|Template Toolkit mod_perl) (Hello|2000)$'
Below is the data. Enjoy!
--Josh
________________________________________________________________
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc. http://www.chamas.com
NodeWorks Link Checking http://www.nodeworks.com
================ mp1 + perl 5.80 no threads
[2003-05-06 11:33:43] Found apache web server at /usr/local/apache/bin/httpd
Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB)
--------- --------- --------- --------- --------- --------- --------- ---------
Apache::ASP v2.55 mod_perl 2000 h2000.asp 392.6 5890 15.00 0.002547 29025 31336
HTML::Template v2.6 mod_perl 2000 h2000.htm 232.0 3482 15.01 0.004311 29169 20424
mod_perl handler 2000 h2000.pm 966.2 14498 15.01 0.001035 28196 9824
Template v2.09 Toolkit mod_perl 200 h2000.tt 301.8 4528 15.00 0.003313 28906 43168
Apache::ASP v2.55 mod_perl Hello hello.asp 533.7 8008 15.00 0.001874 258 28548
HTML::Template v2.6 mod_perl Hello hello.htm 1174.0 17620 15.01 0.000852 216 16864
mod_perl handler Hello hello.ben 2141.9 32133 15.00 0.000467 214 8528
Template v2.09 Toolkit mod_perl Hel hello.tt 984.2 14776 15.01 0.001016 216 31536
Apache Server Header Tokens
---------------------------
Apache/1.3.27
OpenSSL/0.9.6g
PHP/4.3.0
mod_fastcgi/2.2.12
mod_perl/1.27
mod_ssl/2.8.12
PERL Versions: 5.008
================ mp2 + perl 5.80 no threads, apache prefork mpm
[2003-05-06 11:37:50] Found apache web server at /usr/local/apache2/bin/httpd
Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB)
--------- --------- --------- --------- --------- --------- --------- ---------
Apache::ASP v2.55 mod_perl 2000 h2000.asp 312.1 4733 15.16 0.003204 29051 37528
HTML::Template v2.6 mod_perl 2000 h2000.htm 224.3 3438 15.33 0.004459 29217 26716
mod_perl handler 2000 h2000.pm 1203.5 18246 15.16 0.000831 28244 13796
Template v2.09 Toolkit mod_perl 200 h2000.tt 295.7 4479 15.14 0.003381 28954 48584
Apache::ASP v2.55 mod_perl Hello hello.asp 396.0 5984 15.11 0.002525 284 33740
HTML::Template v2.6 mod_perl Hello hello.htm 1249.6 19655 15.73 0.000800 261 20932
mod_perl handler Hello hello.ben 2568.0 38975 15.18 0.000389 260 4300
Template v2.09 Toolkit mod_perl Hel hello.tt 1039.8 16294 15.67 0.000962 261 36168
Apache Server Header Tokens
---------------------------
Apache/2.0.40
OpenSSL/0.9.6g
PHP/4.2.3
Perl/v5.8.0
Python/2.2.1
mod_perl/1.99_09
mod_python/3.0.1
mod_ssl/2.0.40
PERL Versions: 5.008
================ mp2 + perl 5.80 with threads, apache worker mpm
[2003-05-06 11:42:04] Found apache web server at /usr/local/apache2w/bin/httpd
Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB)
--------- --------- --------- --------- --------- --------- --------- ---------
Apache::ASP v2.55 mod_perl 2000 h2000.asp 260.8 3998 15.33 0.003834 29051 29284
HTML::Template v2.6 mod_perl 2000 h2000.htm 195.9 2967 15.14 0.005104 29217 19488
mod_perl handler 2000 h2000.pm 989.2 15240 15.41 0.001011 28244 16188
Template v2.09 Toolkit mod_perl 200 h2000.tt 267.1 4050 15.16 0.003744 28954 36548
Apache::ASP v2.55 mod_perl Hello hello.asp 342.6 5195 15.16 0.002919 284 28088
HTML::Template v2.6 mod_perl Hello hello.htm 1039.2 16457 15.84 0.000962 261 18488
mod_perl handler Hello hello.ben 2309.3 34931 15.13 0.000433 260 14656
Template v2.09 Toolkit mod_perl Hel hello.tt 884.5 13521 15.29 0.001131 261 30896
Apache Server Header Tokens
---------------------------
Apache/2.0.40
OpenSSL/0.9.6g
PHP/4.2.3
Perl/v5.8.0
Python/2.2.1
mod_perl/1.99_09
mod_python/3.0.1
mod_ssl/2.0.40
PERL Versions: 5.008
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Migration + Threads
Posted by be...@beaucox.com.
On 8 May 2003 at 10:05, Bill Marrs wrote:
> Well, I've decided to move toward migrating my environment to Red Hat 9
> (Linux) and along with that Apache 2 and mod_perl 2 (I am currently using
> RH 7.2, Apache 1.3, and mod_perl 1.26). I use the startup.pl pre-fork load
> of my Perl modules and get decent performance despite massively large httpds.
>
> I'm an Apache::Registry user, and my initial tests (on a test server) seem
> to show that switching to ModPerl::Registry works fine and my site seems
> functional. I haven't done extensive testing yet, though.
>
> My main concern at this point is threads. It looks like RH 9 comes with a
> threaded Perl. From what I've read in poking around, threads may not be
> appropriate in a production environment, that mystery bugs might start
> appearing due to system calls being non-thread safe. I'd really rather
> avoid building perl/Apache/mod_perl, though. I've managed for years to use
> standard RH rpms and this has made admin a lot easier for me.
>
> My plan is to go ahead with more testing of my test=server site under a
> pure threaded Perl, Apache 2, mod_perl 2 environment. Maybe, it will work
> fine and I can just use the standard version of these software packages
> from RH. However, I'm a little afraid that despite my testing, when I
> release to the live/production site, it could all blow up in my face and it
> will be really hard to back-paddle to a non-threaded environment.
>
> I don't suppose there's some way for me to simply turn off threading in
> perl without a rebuild/reinstall? That would be very nice. ...or perhaps,
> a way to just force mod_perl or Apache to not use threads? I may be a
> little confused about all the issues here. My technical understanding of
> Apache and Perl is limited.
>
> Any advice would be appreciated,
>
> TIA,
>
> -bill
>
Hi bill -
I have been using fully threaded Perl (5.8),
Apache 2, mod_perl 2, and Mason in a test
environment for 6+ months, and on 5 production
servers (my personal server and 4 of my
clients' servers) for 4+ months. I have had
_no_ problems related to threading (just plenty
of my dumb mistakes.) I'm not sure, but I
think some of the thread warnings we see are
left over from earlier releases.
I build all of these packages (except Perl)
from source (mod_perl 2 from cvs). The v2
development is moving fast and my distribution's
standard RPMs are from earlier, buggy, versions.
Of course, my results may not be representative.
None of the servers I support are heavily loaded,
and none to really esoteric stuff. In other words,
your milage may vary :)
But - having given my disclaimer - be brave! Go
for it!
By the way, I'm using SuSE 8.1. I like it better
than RedHat.
Aloha => Beau;
Re: Migration + Threads
Posted by Perrin Harkins <pe...@elem.com>.
On Thu, 2003-05-08 at 18:21, Dave Rolsky wrote:
> On Thu, 8 May 2003, Perrin Harkins wrote:
>
> > > I'd really rather
> > > avoid building perl/Apache/mod_perl, though. I've managed for years to use
> > > standard RH rpms and this has made admin a lot easier for me.
> >
> > Building them is quite easy on a linux system. You should consider it
> > if you are concerned about performance and mystery bugs.
>
> And then you lose the advantage of being able to install new packages to
> fix bugs, upgrade, etc., and you're stuck building your own forever, and
> the default build won't respect your distro's filesystem layout, and so
> on. And if you have 10 web servers you now have to build it ten times.
I wasn't advocating building from source on every target machine. Most
places I've worked at built our own and then made RPMs from them so we
could put them on a cluster of machines and ensure that everyone was
using the same one.
> A better solution imght be to build your own packages, based on the vendor
> packages, and maintain the changes a set of patches to the vendor source
> package, or something like that.
Changing the spec file for a source RPM and recompiling is pretty easy
to do. One problem with Red Hat 8 and 9 is that they use a locale
setting (en_US.UTF-8) that breaks Perl in many cases. Many CPAN
modules, and perl 5.8 itself, will not pass their tests unless you
change this to something sane like en_US.ISO8859-1. This is done in
/etc/sysconfig/i18n.
- Perrin
Re: Migration + Threads
Posted by Dave Rolsky <au...@urth.org>.
On Thu, 8 May 2003, Perrin Harkins wrote:
> > I'd really rather
> > avoid building perl/Apache/mod_perl, though. I've managed for years to use
> > standard RH rpms and this has made admin a lot easier for me.
>
> Building them is quite easy on a linux system. You should consider it
> if you are concerned about performance and mystery bugs.
And then you lose the advantage of being able to install new packages to
fix bugs, upgrade, etc., and you're stuck building your own forever, and
the default build won't respect your distro's filesystem layout, and so
on. And if you have 10 web servers you now have to build it ten times.
A better solution imght be to build your own packages, based on the vendor
packages, and maintain the changes a set of patches to the vendor source
package, or something like that.
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
Re: Migration + Threads
Posted by Perrin Harkins <pe...@elem.com>.
On Thu, 2003-05-08 at 10:05, Bill Marrs wrote:
> My main concern at this point is threads. It looks like RH 9 comes with a
> threaded Perl. From what I've read in poking around, threads may not be
> appropriate in a production environment, that mystery bugs might start
> appearing due to system calls being non-thread safe.
Also, threads have a significant impact on performance. See the
benchmarks posted recently by Joshua Chamas.
> I'd really rather
> avoid building perl/Apache/mod_perl, though. I've managed for years to use
> standard RH rpms and this has made admin a lot easier for me.
Building them is quite easy on a linux system. You should consider it
if you are concerned about performance and mystery bugs.
> I don't suppose there's some way for me to simply turn off threading in
> perl without a rebuild/reinstall? That would be very nice. ...or perhaps,
> a way to just force mod_perl or Apache to not use threads?
The prefork MPM doesn't use threads, but you still pay a performance
penalty for having them compiled into perl at all.
- Perrin
Re: Migration + Performance
Posted by Bill Marrs <bi...@apocalypse.org>.
>As Stas pointed out in the thread regarding the recent Benchmarks (see Ged's
>reply) you will see performance degredation using Threaded perl with a
>prefork
>MPM. This is because (?) threaded perl has a lot more overhead with it
>with regards
>to maintaining thread memory etc, which is wasted in a prefork enviroment.
I suspect that this performance degradation may be negligible compared to
other factors in my case. It's too bad there isn't an easier way to flip
the switch on Perl for threaded or not. A performance boost would be nice.
I sounds like building a 2nd non-threaded Perl on the system to test this
out maybe be worth a shot.
-bill
Re: Migration + Performance
Posted by Bill Marrs <bi...@apocalypse.org>.
My problem may be unrelated to threads/MPMs/etc.
Oddly enough, I tracked down my performance issue to a DBI call.
I fill a couple hash tables via a DBI prepare/execute/fetchrow_array
loop. This loop is taking 2 seconds to complete for 15,000 rows. The DB
call itself when called via mysql command-line takes .3 seconds. It looks
like it's directly related to the number of rows I get back. If I limit
it, the loop takes a lot less time and the site performs better (maybe even
better than before the upgrade).
I'm going to look into using alternate DBI calls to see if I can find one
that performs better when there are a lot of rows returned. ...and
generally investigate DBI advice/tips/help.
Thanks
-bill
Re: Migration + Performance
Posted by ch...@prather.org.
On 9 May 2003 at 7:50, Bill Marrs wrote:
> I'm going to try plugging in Apache::DProf to see if I can find a smoking
> gun. Perhaps, it's just some Perl code that is slow in this new 5.8
> version that I can side-step or re-write. I haven't had much look with
> DProf in the past though (it seems to miss most of the subroutines being
> called).
>
> I'm not sure where the likely smoking gun is. Is it Apache's new thread
> model? Is it threaded Perl (seems unlikely), is it mod_perl? (again,
> unlikely?). ...or the new Perl (I'm going to look here first).
As Stas pointed out in the thread regarding the recent Benchmarks (see Ged's
reply) you will see performance degredation using Threaded perl with a prefork
MPM. This is because (?) threaded perl has a lot more overhead with it with regards
to maintaining thread memory etc, which is wasted in a prefork enviroment.
Based off Stas' comments in the Benchmark thread (and because you say that
you're using Pure Perl modules) that you may find using a Threaded/Worker MPM
with some tweaking of the PerlInterpreter settings to be significantly faster than the
current prefork implimentation you have (and possibly faster than Apache1/mp1)
Take this advice with a grain of salt mind. I haven't tested any of this myself yet,
and please report back with your results.
-Chris
Re: Migration + Performance
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi there,
On Fri, 9 May 2003, Bill Marrs wrote:
> However, I quickly discovered that this new setup: Apache
> 2(server/mpm/prefork), ModPerl 2, Perl 5.8.0 threaded, is noticeably slower
> than my old Apache 1.3, MP1, non-threaded Perl 5.6.1.
[snip]
> I'm not sure where the likely smoking gun is. Is it Apache's new thread
> model? Is it threaded Perl (seems unlikely), is it mod_perl? (again,
> unlikely?). ...or the new Perl (I'm going to look here first).
Did you see the recent thread on benchmarking started by Josh Chamas?
It seems that your experience mirrors his results.
73,
Ged.
Re: Migration + Performance
Posted by Bill Marrs <bi...@apocalypse.org>.
Thanks for the replies to my earlier post. I'm now fairly confident that
Threaded Perl will not break my web application. After some testing, it
seems to be working fine and my code is all native Perl, so it should be
fine as far as I can tell.
However, I quickly discovered that this new setup: Apache
2(server/mpm/prefork), ModPerl 2, Perl 5.8.0 threaded, is noticeably slower
than my old Apache 1.3, MP1, non-threaded Perl 5.6.1.
I'm still hoping that I can get by without having to build Perl/Apache by
hand, so I'm trying to find any configuration settings I might be able to
tweak to get things working as fast as they were.
Unfortunately, I don't have good previous numbers but, roughly my pages
which had been taking around 1 second to load not take about 2 seconds, and
this ratio tends to scale up the larger they are with some more complicated
pages taken several seconds. This is fairly unacceptable performance-wise,
so I'm very concerned about this.
Of course my site is fairly complicated, and I just wiped and reinstalled
the OS on this test server, so there's a lot of new things that could be
the problem. I did check on the database(MySQL) and it seems as fast as ever.
My impression, from watching the page load is that it's just slow to output
the text. I see the top left logo on the page come up fast, but then the
navigation bars and page content takes a second or two.
I'm going to try plugging in Apache::DProf to see if I can find a smoking
gun. Perhaps, it's just some Perl code that is slow in this new 5.8
version that I can side-step or re-write. I haven't had much look with
DProf in the past though (it seems to miss most of the subroutines being
called).
I'm not sure where the likely smoking gun is. Is it Apache's new thread
model? Is it threaded Perl (seems unlikely), is it mod_perl? (again,
unlikely?). ...or the new Perl (I'm going to look here first).
-bill
Re: Migration + Threads
Posted by Stas Bekman <st...@stason.org>.
[...]
> My main concern at this point is threads. It looks like RH 9 comes with
> a threaded Perl. From what I've read in poking around, threads may not
> be appropriate in a production environment, that mystery bugs might
> start appearing due to system calls being non-thread safe. I'd really
> rather avoid building perl/Apache/mod_perl, though. I've managed for
> years to use standard RH rpms and this has made admin a lot easier for me.
It's rather simple:
As Perrin has said, under prefork mpm, you have no problem using
threads-enabled Perl... unless your mod_perl handler spawns its own threads,
which won't make any sense to do, so we won't even delve into that possibility.
Under threaded mpms, read this:
http://perl.apache.org/docs/2.0/user/coding/coding.html#Thread_environment_Issues
Plus I should probably add to that section, that 3rd party modules using C
extensions might be thread-unsafe. So if you don't use such modules, you have
nothing to worry about. If you do, and your software is not life-critical, I'd
just give it a try and if the problem arises, switch back to prefork and
investigate the problem. If your software is life-critical, then you have to
investigate all 3rd party modules that you use, but you should be doing that
already threads or not threads...
__________________________________________________________________
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
Migration + Threads
Posted by Bill Marrs <bi...@apocalypse.org>.
Well, I've decided to move toward migrating my environment to Red Hat 9
(Linux) and along with that Apache 2 and mod_perl 2 (I am currently using
RH 7.2, Apache 1.3, and mod_perl 1.26). I use the startup.pl pre-fork load
of my Perl modules and get decent performance despite massively large httpds.
I'm an Apache::Registry user, and my initial tests (on a test server) seem
to show that switching to ModPerl::Registry works fine and my site seems
functional. I haven't done extensive testing yet, though.
My main concern at this point is threads. It looks like RH 9 comes with a
threaded Perl. From what I've read in poking around, threads may not be
appropriate in a production environment, that mystery bugs might start
appearing due to system calls being non-thread safe. I'd really rather
avoid building perl/Apache/mod_perl, though. I've managed for years to use
standard RH rpms and this has made admin a lot easier for me.
My plan is to go ahead with more testing of my test=server site under a
pure threaded Perl, Apache 2, mod_perl 2 environment. Maybe, it will work
fine and I can just use the standard version of these software packages
from RH. However, I'm a little afraid that despite my testing, when I
release to the live/production site, it could all blow up in my face and it
will be really hard to back-paddle to a non-threaded environment.
I don't suppose there's some way for me to simply turn off threading in
perl without a rebuild/reinstall? That would be very nice. ...or perhaps,
a way to just force mod_perl or Apache to not use threads? I may be a
little confused about all the issues here. My technical understanding of
Apache and Perl is limited.
Any advice would be appreciated,
TIA,
-bill
Re: [mp2] Benchmarks comparing mp2 vs. mp1
Posted by Stas Bekman <st...@stason.org>.
Gunther Birznieks wrote:
> So... Is there an informal rule of thumb as to which platforms threads
> would work better on than others? It seems like something someone would
> want to know in the install docs like "XYZ OS works really well if you
> use the threaded model, but if you use ABC OS, then you should stick to
> pre-fork model because threads do not work as well on ABC OS"...
Two things:
1) experiment: benchmark *your* code using the prefork and worker mpms and
choose what does it for you.
2) we will gain more knowledge and start documenting it if people will start
contributing it. My note was more of waving hands, because I've read various
complaints on various lists going like: "btw, on platform Foo release Bar the
threads implementation sucks".
It's very impractical to try to provide ultimate benchmarks that you can base
your decisions on, if you don't have exactly the same kind of hardware
components, running software, people managing it and sun radiation.
I always repeat: benchmark your particular setup and see whether you are happy
with it. The benchmarking docs show you how to benchmark, and how to make
conclusions based on the received results, they don't try to provide ultimate
rules of what's the right thing to do.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [mp2] Benchmarks comparing mp2 vs. mp1
Posted by Stas Bekman <st...@stason.org>.
Gunther Birznieks wrote:
> So... Is there an informal rule of thumb as to which platforms threads
> would work better on than others? It seems like something someone would
> want to know in the install docs like "XYZ OS works really well if you
> use the threaded model, but if you use ABC OS, then you should stick to
> pre-fork model because threads do not work as well on ABC OS"...
Two things:
1) experiment: benchmark *your* code using the prefork and worker mpms and
choose what does it for you.
2) we will gain more knowledge and start documenting it if people will start
contributing it. My note was more of waving hands, because I've read various
complaints on various lists going like: "btw, on platform Foo release Bar the
threads implementation sucks".
It's very impractical to try to provide ultimate benchmarks that you can base
your decisions on, if you don't have exactly the same kind of hardware
components, running software, people managing it and sun radiation.
I always repeat: benchmark your particular setup and see whether you are happy
with it. The benchmarking docs show you how to benchmark, and how to make
conclusions based on the received results, they don't try to provide ultimate
rules of what's the right thing to do.
__________________________________________________________________
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
Re: [mp2] Benchmarks comparing mp2 vs. mp1
Posted by Gunther Birznieks <gu...@extropia.com>.
This thread is interesting... (slight pun intended)...
So... Is there an informal rule of thumb as to which platforms threads
would work better on than others? It seems like something someone would
want to know in the install docs like "XYZ OS works really well if you
use the threaded model, but if you use ABC OS, then you should stick to
pre-fork model because threads do not work as well on ABC OS"...
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 stored in threaded env, and more CPU cycles, since more things
> happen under threaded env. However if you do take the benefit of
> threads (having many perl interpreters in one process), on a platform
> with a solid and efficient threads implementation, you are most likely
> to have a better performance and memory usage than with the prefork
> mpm (assuming that you have no mutex lock bottlenecks, resulting from
> crude workarounds (serialization) to thread-unsafe libs.
>
>>> 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.
>>>
>>
>> Right, the setup for the benchmarks I ran anticipated 3rd party modules
>> causing segfaults randomly, which is true on many apache installations
>> I have seen.
>
>
> Your service won't disappear when this happens, Apache will restart a
> new process immediately. However all currently served requests will be
> aborted. Assuming that your production env does not ever segfault
> having 1 process and many threads is the best solution.
>
>>> 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.
>>
>>
>>
>> This almost sounds like an argument against using the threaded
>> architecture
>> on those platforms. At the very least, it should inspire one to have
>> more than
>> a few processes in worker mpm mode, so at least the processes can
>> context
>> switch effectively, right?
>
>
> You probably won't want to use the threaded mpm at all in that case.
> You will either find that the prefork solution is good enough for your
> needs or you will move to a different platform/version which doesn't
> have this limitation.
>
> And last but not least, do not use threads unless you need them or you
> know that it'll make things better. Do not even compile perl with
> -Dusethreads if you aren't going to use them. Preforking is a proved
> stable model that works for 1.3 and will work just fine for many
> people with 2.0. Once you enter the threaded world there are too many
> potential problems that you will have to deal with and which are often
> not under your control, or your understanding. Of course CPAN module
> developers have no choice but to try to make their code work correctly
> under all MPMs.
>
> __________________________________________________________________
> 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
>
>
>
Re: [mp2] Benchmarks comparing mp2 vs. mp1
Posted by Stas Bekman <st...@stason.org>.
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
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
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [mp2] Benchmarks comparing mp2 vs. mp1
Posted by Stas Bekman <st...@stason.org>.
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
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
Re: [mp2] Benchmarks comparing mp2 vs. mp1
Posted by Josh Chamas <jo...@chamas.com>.
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? :)
Thanks,
Josh
________________________________________________________________
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc. http://www.chamas.com
NodeWorks Link Checking http://www.nodeworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [mp2] Benchmarks comparing mp2 vs. mp1
Posted by Gunther Birznieks <gu...@extropia.com>.
This thread is interesting... (slight pun intended)...
So... Is there an informal rule of thumb as to which platforms threads
would work better on than others? It seems like something someone would
want to know in the install docs like "XYZ OS works really well if you
use the threaded model, but if you use ABC OS, then you should stick to
pre-fork model because threads do not work as well on ABC OS"...
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 stored in threaded env, and more CPU cycles, since more things
> happen under threaded env. However if you do take the benefit of
> threads (having many perl interpreters in one process), on a platform
> with a solid and efficient threads implementation, you are most likely
> to have a better performance and memory usage than with the prefork
> mpm (assuming that you have no mutex lock bottlenecks, resulting from
> crude workarounds (serialization) to thread-unsafe libs.
>
>>> 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.
>>>
>>
>> Right, the setup for the benchmarks I ran anticipated 3rd party modules
>> causing segfaults randomly, which is true on many apache installations
>> I have seen.
>
>
> Your service won't disappear when this happens, Apache will restart a
> new process immediately. However all currently served requests will be
> aborted. Assuming that your production env does not ever segfault
> having 1 process and many threads is the best solution.
>
>>> 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.
>>
>>
>>
>> This almost sounds like an argument against using the threaded
>> architecture
>> on those platforms. At the very least, it should inspire one to have
>> more than
>> a few processes in worker mpm mode, so at least the processes can
>> context
>> switch effectively, right?
>
>
> You probably won't want to use the threaded mpm at all in that case.
> You will either find that the prefork solution is good enough for your
> needs or you will move to a different platform/version which doesn't
> have this limitation.
>
> And last but not least, do not use threads unless you need them or you
> know that it'll make things better. Do not even compile perl with
> -Dusethreads if you aren't going to use them. Preforking is a proved
> stable model that works for 1.3 and will work just fine for many
> people with 2.0. Once you enter the threaded world there are too many
> potential problems that you will have to deal with and which are often
> not under your control, or your understanding. Of course CPAN module
> developers have no choice but to try to make their code work correctly
> under all MPMs.
>
> __________________________________________________________________
> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [mp2] Benchmarks comparing mp2 vs. mp1
Posted by Josh Chamas <jo...@chamas.com>.
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? :)
Thanks,
Josh
________________________________________________________________
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc. http://www.chamas.com
NodeWorks Link Checking http://www.nodeworks.com
Re: [mp2] Benchmarks comparing mp2 vs. mp1
Posted by Stas Bekman <st...@stason.org>.
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 stored in threaded env, and more
CPU cycles, since more things happen under threaded env. However if you do
take the benefit of threads (having many perl interpreters in one process), on
a platform with a solid and efficient threads implementation, you are most
likely to have a better performance and memory usage than with the prefork mpm
(assuming that you have no mutex lock bottlenecks, resulting from crude
workarounds (serialization) to thread-unsafe libs.
>> 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.
>>
>
> Right, the setup for the benchmarks I ran anticipated 3rd party modules
> causing segfaults randomly, which is true on many apache installations
> I have seen.
Your service won't disappear when this happens, Apache will restart a new
process immediately. However all currently served requests will be aborted.
Assuming that your production env does not ever segfault having 1 process and
many threads is the best solution.
>> 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.
>
>
> This almost sounds like an argument against using the threaded architecture
> on those platforms. At the very least, it should inspire one to have
> more than
> a few processes in worker mpm mode, so at least the processes can context
> switch effectively, right?
You probably won't want to use the threaded mpm at all in that case. You will
either find that the prefork solution is good enough for your needs or you
will move to a different platform/version which doesn't have this limitation.
And last but not least, do not use threads unless you need them or you know
that it'll make things better. Do not even compile perl with -Dusethreads if
you aren't going to use them. Preforking is a proved stable model that works
for 1.3 and will work just fine for many people with 2.0. Once you enter the
threaded world there are too many potential problems that you will have to
deal with and which are often not under your control, or your understanding.
Of course CPAN module developers have no choice but to try to make their code
work correctly under all MPMs.
__________________________________________________________________
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
Re: [mp2] Benchmarks comparing mp2 vs. mp1
Posted by Stas Bekman <st...@stason.org>.
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 stored in threaded env, and more
CPU cycles, since more things happen under threaded env. However if you do
take the benefit of threads (having many perl interpreters in one process), on
a platform with a solid and efficient threads implementation, you are most
likely to have a better performance and memory usage than with the prefork mpm
(assuming that you have no mutex lock bottlenecks, resulting from crude
workarounds (serialization) to thread-unsafe libs.
>> 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.
>>
>
> Right, the setup for the benchmarks I ran anticipated 3rd party modules
> causing segfaults randomly, which is true on many apache installations
> I have seen.
Your service won't disappear when this happens, Apache will restart a new
process immediately. However all currently served requests will be aborted.
Assuming that your production env does not ever segfault having 1 process and
many threads is the best solution.
>> 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.
>
>
> This almost sounds like an argument against using the threaded architecture
> on those platforms. At the very least, it should inspire one to have
> more than
> a few processes in worker mpm mode, so at least the processes can context
> switch effectively, right?
You probably won't want to use the threaded mpm at all in that case. You will
either find that the prefork solution is good enough for your needs or you
will move to a different platform/version which doesn't have this limitation.
And last but not least, do not use threads unless you need them or you know
that it'll make things better. Do not even compile perl with -Dusethreads if
you aren't going to use them. Preforking is a proved stable model that works
for 1.3 and will work just fine for many people with 2.0. Once you enter the
threaded world there are too many potential problems that you will have to
deal with and which are often not under your control, or your understanding.
Of course CPAN module developers have no choice but to try to make their code
work correctly under all MPMs.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [mp2] Benchmarks comparing mp2 vs. mp1
Posted by Josh Chamas <jo...@chamas.com>.
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 ).
>
> 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.
>
Right, the setup for the benchmarks I ran anticipated 3rd party modules
causing segfaults randomly, which is true on many apache installations
I have seen.
> 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.
>
This is really good stuff, this was a big complaint of the round robin
Apache process request serving.
>
> 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.
>
Yep, its just the output from my current monolithic benchmark program.
I probably won't be doing many more of these cross server comparisons.
> 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.
This almost sounds like an argument against using the threaded architecture
on those platforms. At the very least, it should inspire one to have more than
a few processes in worker mpm mode, so at least the processes can context
switch effectively, right?
Regards,
Josh
________________________________________________________________
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc. http://www.chamas.com
NodeWorks Link Checking http://www.nodeworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [mp2] Benchmarks comparing mp2 vs. mp1
Posted by Josh Chamas <jo...@chamas.com>.
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 ).
>
> 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.
>
Right, the setup for the benchmarks I ran anticipated 3rd party modules
causing segfaults randomly, which is true on many apache installations
I have seen.
> 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.
>
This is really good stuff, this was a big complaint of the round robin
Apache process request serving.
>
> 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.
>
Yep, its just the output from my current monolithic benchmark program.
I probably won't be doing many more of these cross server comparisons.
> 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.
This almost sounds like an argument against using the threaded architecture
on those platforms. At the very least, it should inspire one to have more than
a few processes in worker mpm mode, so at least the processes can context
switch effectively, right?
Regards,
Josh
________________________________________________________________
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc. http://www.chamas.com
NodeWorks Link Checking http://www.nodeworks.com
Re: [mp2] Benchmarks comparing mp2 vs. mp1
Posted by Stas Bekman <st...@stason.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [mp2] Benchmarks comparing mp2 vs. mp1
Posted by Stas Bekman <st...@stason.org>.
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