Well then, why doesn't somebody just make an Apache directive to control how
hits are divvied out to the children? Something like
NextChild most-recent
NextChild least-recent
NextChild (blah...)
but more well-considered in name. Not sure whether a config directive
would do it, or whether it would have to be a startup command-line
switch. Or maybe a directive that can only happen in a startup config
file, not a .htaccess file.
[EMAIL PROTECTED] (Gunther Birznieks) wrote:
>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/
>
>
------------------- -------------------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED] The Math Forum
