Loading ...
Sorry, an error occurred while loading the content.
 

[mp2] Benchmarks comparing mp2 vs. mp1

Expand Messages
  • Josh Chamas
    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
    Message 1 of 8 , May 6, 2003
      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@...
      For additional commands, e-mail: asp-help@...
    • Stas Bekman
      ... [...] ... 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,
      Message 2 of 8 , May 6, 2003
        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@... http://use.perl.org http://apacheweek.com
        http://modperlbook.org http://apache.org http://ticketmaster.com


        ---------------------------------------------------------------------
        To unsubscribe, e-mail: asp-unsubscribe@...
        For additional commands, e-mail: asp-help@...
      • Josh Chamas
        ... 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
        Message 3 of 8 , May 6, 2003
          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@...
          For additional commands, e-mail: asp-help@...
        • Stas Bekman
          ... 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
          Message 4 of 8 , May 6, 2003
            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@... http://use.perl.org http://apacheweek.com
            http://modperlbook.org http://apache.org http://ticketmaster.com


            ---------------------------------------------------------------------
            To unsubscribe, e-mail: asp-unsubscribe@...
            For additional commands, e-mail: asp-help@...
          • Josh Chamas
            ... 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
            Message 5 of 8 , May 6, 2003
              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@...
              For additional commands, e-mail: asp-help@...
            • Stas Bekman
              ... 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
              Message 6 of 8 , May 6, 2003
                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@... http://use.perl.org http://apacheweek.com
                http://modperlbook.org http://apache.org http://ticketmaster.com


                ---------------------------------------------------------------------
                To unsubscribe, e-mail: asp-unsubscribe@...
                For additional commands, e-mail: asp-help@...
              • Gunther Birznieks
                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?
                Message 7 of 8 , May 6, 2003
                  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@... http://use.perl.org http://apacheweek.com
                  > http://modperlbook.org http://apache.org http://ticketmaster.com
                  >
                  >
                  >



                  ---------------------------------------------------------------------
                  To unsubscribe, e-mail: asp-unsubscribe@...
                  For additional commands, e-mail: asp-help@...
                • Stas Bekman
                  ... 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
                  Message 8 of 8 , May 7, 2003
                    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@... http://use.perl.org http://apacheweek.com
                    http://modperlbook.org http://apache.org http://ticketmaster.com


                    ---------------------------------------------------------------------
                    To unsubscribe, e-mail: asp-unsubscribe@...
                    For additional commands, e-mail: asp-help@...
                  Your message has been successfully submitted and would be delivered to recipients shortly.