FYI --
Sam just posted this to the speedycgi list just now.
>X-Authentication-Warning: www.newlug.org: majordom set sender to
>[EMAIL PROTECTED] using -f
>To: [EMAIL PROTECTED]
>Subject: [speedycgi] Speedycgi scales better than mod_perl with scripts
>that contain un-shared memory
>Date: Wed, 20 Dec 2000 20:18:37 -0800
>From: Sam Horrocks <[EMAIL PROTECTED]>
>Sender: [EMAIL PROTECTED]
>Reply-To: [EMAIL PROTECTED]
>
>Just a point in speedy's favor, for anyone interested in performance tuning
>and scalability.
>
>A lot of mod_perl performance tuning involves trying to keep from creating
>"un-shared" memory - that is memory that a script uses while handling
>a request that is private to that script. All perl scripts use some
>amount of un-shared memory - anything derived from user-input to the
>script via queries or posts for example has to be un-shared because it
>is unique to that run of that script.
>
>You can read all about mod_perl shared memory issues at:
>
> http://perl.apache.org/guide/performance.html#Sharing_Memory
>
>The underlying problem in mod_perl is that apache likes to spread out
>web requests to as many httpd's, and therefore as many mod_perl interpreters,
>as possible using an LRU selection processes for picking httpd's. For
>static web-pages where there is almost zero un-shared memory, the selection
>process doesn't matter much. But when you load in a perl script with
>un-shared memory, it can really bog down the server.
>
>In SpeedyCGI's case, all perl memory is un-shared because there's no
>parent to pre-load any of the perl code into memory. It could benefit
>somewhat from reducing this amount of un-shared memory if it had such
>a feature, but the fact that SpeedyCGI chooses backends using an MRU
>selection process means that it is much less prone to problems that
>un-shared memory can cause.
>
>I wanted to see how this played out in real benchmarks, so I wrote the
>following test script that uses un-shared memory:
>
>use CGI;
>$x = 'x' x 50000; # Use some un-shared memory (*not* a memory leak)
>my $cgi = CGI->new();
>print $cgi->header();
>print "Hello ";
>print "World";
>
>I then ran ab to benchmark how well mod_speedycgi did versus mod_perl
>on this script. When using no concurrency ("ab -c 1 -n 10000")
>mod_speedycgi and mod_perl come out about the same. However, by
>increasing the concurrency level, I found that mod_perl performance drops
>off drastically, while mod_speedycgi does not. In my case at about level
>100, the rps number drops by 50% and the system starts paging to disk
>while using mod_perl, whereas the mod_speedycgi numbers stay at about
>the same level.
>
>The problem is that at a high concurrency level, mod_perl is using lots
>and lots of different perl-interpreters to handle the requests, each
>with its own un-shared memory. It's doing this due to its LRU design.
>But with SpeedyCGI's MRU design, only a few speedy_backends are being used
>because as much as possible it tries to use the same interpreter over and
>over and not spread out the requests to lots of different interpreters.
>Mod_perl is using lots of perl-interpreters, while speedycgi is only using
>a few. mod_perl is requiring that lots of interpreters be in memory in
>order to handle the requests, wherase speedy only requires a small number
>of interpreters to be in memory. And this is where the paging comes in -
>at a high enough concurency level, mod_perl starts using lots of memory
>to hold all of those interpreters, eventually running out of real memory
>and at that point it has to start paging. And when the paging starts,
>the performance really nose-dives.
>
>With SpeedyCGI, at the same concurrency level, the total memory
>requirements for all the intepreters are much much smaller. Eventually
>under a large enough load and with enough un-shared memory, SpeedyCGI
>would probably have to start paging too. But due to its design the point
>at which SpeedyCGI will start doing this is at a much higher level than
>with mod_perl.
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Web Technology Company
http://www.extropia.com/
