Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl with scripts that contain un-shared memory
> "KW" == Ken Williams <[EMAIL PROTECTED]> writes: KW> Well then, why doesn't somebody just make an Apache directive to KW> control how hits are divvied out to the children? Something like According to memory, mod_perl 2.0 uses a most-recently-used strategy to pull perl interpreters from the thread pool. It sounds to me like with apache 2.0 in thread-mode and mod_perl 2.0 you get the same effect of using the proxy front end that we currently need. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl with scripts that contain un-shared memory
At 09:53 AM 12/21/00 -0500, Joe Schaefer wrote: >[ Sorry for accidentally spamming people on the > list. I was ticked off by this "benchmark", > and accidentally forgot to clean up the reply > names. I won't let it happen again :( ] Not sure what you mean here. Some people like the duplicate reply names especially as the mod_perl list is still a bit slow on responding. I know I prefer to see replies to my messages ASAP and they tend to come faster if I am CCed on the list. >All kidding aside, the problem with modperl is memory consumption, >and to use modperl seriously, you currently have to code around >that (preloading commonly used modules like CGI, or running it in >a frontend/backend config similar to FastCGI.) FastCGI and modperl >are fundamentally different technologies. Both have the ability >to accelerate CGI scripts; however, modperl can do quite a bit >more than that. > >Claimed benchmarks that are designed to exploit this memory issue >are quite silly, especially when the actual results are never >revealed. It's overzealous advocacy or FUD, depending on which >side of the fence you are sitting on. I think I get your point on the first paragraph. But the 2nd paragraph is odd. Are you classifying the original post as being overzealous advocacy or FUD? I don't think I would classify it as such. I could see it bordering on FUD if there was one benchmark which Sam produced and he just posted "SpeedyCGI is faster than mod_perl" without providing any details. But instead he crafted an experiment to show that in this particular case (and some applications do satisfy this case) SpeedyCGI has a particular benefit. This is why people use different tools for different jobs -- because architecturally they are designed for different things. SpeedyCGI is designed in a different way from mod_perl. What I believe Sam is saying is that there is a particular real-world scenario where SpeedyCGI likely has better performance benefits to mod_perl. Discouraging the posting of experimental information like this is where the FUD will lie. This isn't an advertisement in ComputerWorld by Microsoft or Oracle, it's a posting on a mailing list. Open for discussion.
Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl with scripts that contain un-shared memory
Gunther Birznieks <[EMAIL PROTECTED]> writes: > But instead he crafted an experiment to show that in this particular case > (and some applications do satisfy this case) SpeedyCGI has a particular > benefit. And what do I have to do to repeat it? Unlearn everything in Stas' guide? > > This is why people use different tools for different jobs -- because > architecturally they are designed for different things. SpeedyCGI is > designed in a different way from mod_perl. What I believe Sam is saying is > that there is a particular real-world scenario where SpeedyCGI likely has > better performance benefits to mod_perl. Sure, and that's why some people use it. But to say "Speedycgi scales better than mod_perl with scripts that contain un-shared memory" is to me quite similar to saying "SUV's are better than cars since they're safer to drive drunk in." > > Discouraging the posting of experimental information like this is where the > FUD will lie. This isn't an advertisement in ComputerWorld by Microsoft or > Oracle, it's a posting on a mailing list. Open for discussion. Maybe I'm wrong about this, but I didn't see any mention of the apparatus used in his experiment. I only saw what you posted, and your post had only anecdotal remarks of results without detailing any config info. I'm all for free and open discussions because they can point to interesting new ideas. However, some attempt at full disclosure (comments on the config used are as important important than anecdotal remarks about the results) is necessary so objective opinions can be formed. -- Joe Schaefer
Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl with scripts that contain un-shared memory
[ Sorry for accidentally spamming people on the list. I was ticked off by this "benchmark", and accidentally forgot to clean up the reply names. I won't let it happen again :( ] Matt Sergeant <[EMAIL PROTECTED]> writes: > On Thu, 21 Dec 2000, Ken Williams wrote: > > > 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. > > Probably nobody wants to do it because Apache 2.0 fixes this "bug". > KeepAlive On :) All kidding aside, the problem with modperl is memory consumption, and to use modperl seriously, you currently have to code around that (preloading commonly used modules like CGI, or running it in a frontend/backend config similar to FastCGI.) FastCGI and modperl are fundamentally different technologies. Both have the ability to accelerate CGI scripts; however, modperl can do quite a bit more than that. Claimed benchmarks that are designed to exploit this memory issue are quite silly, especially when the actual results are never revealed. It's overzealous advocacy or FUD, depending on which side of the fence you are sitting on. -- Joe Schaefer
Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl with scripts that contain un-shared memory
On Thu, 21 Dec 2000, Ken Williams wrote: > 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. Probably nobody wants to do it because Apache 2.0 fixes this "bug". -- /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl with scripts that contain un-shared memory
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 5; # 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 1")
>>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
Fwd: [speedycgi] Speedycgi scales better than mod_perl with scripts that contain un-shared memory
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 5; # 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 1")
>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/
