<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: More about Performance Tuning</title>
	<atom:link href="http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/</link>
	<description>Stuart Herbert's PHP Blog - Architecture, Code, and Hosting</description>
	<pubDate>Sat, 05 Jul 2008 20:52:16 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: &#160; Stuart Herbert's Blog: More about Performance Tuning&#160;by&#160;Joe McLaughlin&#8217;s Blog</title>
		<link>http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-15757</link>
		<dc:creator>&#160; Stuart Herbert's Blog: More about Performance Tuning&#160;by&#160;Joe McLaughlin&#8217;s Blog</dc:creator>
		<pubDate>Wed, 27 Feb 2008 07:45:05 +0000</pubDate>
		<guid isPermaLink="false">http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-15757</guid>
		<description>[...] off of a previous article from Mike Willbanks, Stuart Herbert has posted some of his own thoughts on tuning and tweaking your applications for the best performance you can get out of them.   [...]</description>
		<content:encoded><![CDATA[<p>[...] off of a previous article from Mike Willbanks, Stuart Herbert has posted some of his own thoughts on tuning and tweaking your applications for the best performance you can get out of them.   [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: TuxLives</title>
		<link>http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-15112</link>
		<dc:creator>TuxLives</dc:creator>
		<pubDate>Thu, 21 Feb 2008 17:51:50 +0000</pubDate>
		<guid isPermaLink="false">http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-15112</guid>
		<description>I have yet to see a good comment/test around reducing include calls and function overhead.

IE: By including all functions in one file, you make only one call to the filesystem to include it, but you are not instantiating all those functions (which you may or may not need).

I'd love to know what is the crossover point?</description>
		<content:encoded><![CDATA[<p>I have yet to see a good comment/test around reducing include calls and function overhead.</p>
<p>IE: By including all functions in one file, you make only one call to the filesystem to include it, but you are not instantiating all those functions (which you may or may not need).</p>
<p>I&#8217;d love to know what is the crossover point?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Hacking Ajax &#124; Links: PHP Performance</title>
		<link>http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-14127</link>
		<dc:creator>Hacking Ajax &#124; Links: PHP Performance</dc:creator>
		<pubDate>Wed, 13 Feb 2008 20:02:32 +0000</pubDate>
		<guid isPermaLink="false">http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-14127</guid>
		<description>[...] an excellent collection of web app performance tips. The loop example alone is worth the read. Then Stuart Herbert picks it up with some thoughts on XCache + Zend Optimizer + [...]</description>
		<content:encoded><![CDATA[<p>[...] an excellent collection of web app performance tips. The loop example alone is worth the read. Then Stuart Herbert picks it up with some thoughts on XCache + Zend Optimizer + [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Willbanks</title>
		<link>http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-13728</link>
		<dc:creator>Mike Willbanks</dc:creator>
		<pubDate>Sun, 10 Feb 2008 05:52:29 +0000</pubDate>
		<guid isPermaLink="false">http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-13728</guid>
		<description>@Anthony
The difference between Apache and Lighttp is really not that large.  You can certainly performance tune apache taking out many of the default modules to make it perform at a much higher rate.  One of the reasons for running 2 web servers on a local box is to have 1 for sending out non-dynamic content and one for processing in this case PHP.

This is where squid is extremely helpful if you want the port to be blind to the external user.  Having squid sit in front of your web servers caching certain items and then passing the request onto apache or lighttpd for it's respective items.</description>
		<content:encoded><![CDATA[<p>@Anthony<br />
The difference between Apache and Lighttp is really not that large.  You can certainly performance tune apache taking out many of the default modules to make it perform at a much higher rate.  One of the reasons for running 2 web servers on a local box is to have 1 for sending out non-dynamic content and one for processing in this case PHP.</p>
<p>This is where squid is extremely helpful if you want the port to be blind to the external user.  Having squid sit in front of your web servers caching certain items and then passing the request onto apache or lighttpd for it&#8217;s respective items.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anthony Ferrara</title>
		<link>http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-12916</link>
		<dc:creator>Anthony Ferrara</dc:creator>
		<pubDate>Sun, 03 Feb 2008 18:25:18 +0000</pubDate>
		<guid isPermaLink="false">http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-12916</guid>
		<description>I agree with Trophaeum.  I currently run a FCgi powered php site that's seen over 900 requests/sec (Single dual xeon server with 2gb ram).  Never had a problem (but I'm also not using Apache).  About Zend Opimizer, all testing I've done shows it is absolutely not worth it.  While it may make a very slight improvement in load times for specific scripts, it does slow down others (based on my testing).

I like APC, but Xcache is the best out there.  It's compatable with FastCGI, light, and FAST.  As for size limitations for memcache, don't forget that xcache can store userland vars as well... 

As far as serving static content, Apache + mod_php does not serve static content well.  Apache (or lighttpd), with php as FastCGI serve static content quite well...

I really question the numbers on IE6 pre SP1 installs... I run a few very high traffic sites, and IE6 makes up an average of 25% of traffic.  So, does that mean 1/3 of all IE 6 users are still using &#60; SP1?

Moving the DB to a separate box is only a fix SOMETIMES.  It will only help if you are disc, CPU or memory bound.  Don't forget, that running a DB locally has VERY little network overhead, but running it on a separate box adds latency.  While the latency is very small, it adds up on every query.  Plus, semi large result sets will tie up network bandwidth (a 100kb result will take about 8ms to transfer (no latency) over a 100mbit line.  That adds up quickly...

I notice you mention using Lighttpd for static content.  Why not use it for PHP as well (as a FastCGI dispatcher)?  It's MUCH more simple, easier to maintain, and cheaper (only one server needed).  All the tests I have done between Apache and Lighttpd, Lighttpd beats Apache hands down in all tests (and some very significantly).  For example, mod_php supported 200 req/sec at 100% CPU.  Lighttpd+Fcgi supported 2000 req/sec of the same script at 50% CPU...

Just my comments here..</description>
		<content:encoded><![CDATA[<p>I agree with Trophaeum.  I currently run a FCgi powered php site that&#8217;s seen over 900 requests/sec (Single dual xeon server with 2gb ram).  Never had a problem (but I&#8217;m also not using Apache).  About Zend Opimizer, all testing I&#8217;ve done shows it is absolutely not worth it.  While it may make a very slight improvement in load times for specific scripts, it does slow down others (based on my testing).</p>
<p>I like APC, but Xcache is the best out there.  It&#8217;s compatable with FastCGI, light, and FAST.  As for size limitations for memcache, don&#8217;t forget that xcache can store userland vars as well&#8230; </p>
<p>As far as serving static content, Apache + mod_php does not serve static content well.  Apache (or lighttpd), with php as FastCGI serve static content quite well&#8230;</p>
<p>I really question the numbers on IE6 pre SP1 installs&#8230; I run a few very high traffic sites, and IE6 makes up an average of 25% of traffic.  So, does that mean 1/3 of all IE 6 users are still using &lt; SP1?</p>
<p>Moving the DB to a separate box is only a fix SOMETIMES.  It will only help if you are disc, CPU or memory bound.  Don&#8217;t forget, that running a DB locally has VERY little network overhead, but running it on a separate box adds latency.  While the latency is very small, it adds up on every query.  Plus, semi large result sets will tie up network bandwidth (a 100kb result will take about 8ms to transfer (no latency) over a 100mbit line.  That adds up quickly&#8230;</p>
<p>I notice you mention using Lighttpd for static content.  Why not use it for PHP as well (as a FastCGI dispatcher)?  It&#8217;s MUCH more simple, easier to maintain, and cheaper (only one server needed).  All the tests I have done between Apache and Lighttpd, Lighttpd beats Apache hands down in all tests (and some very significantly).  For example, mod_php supported 200 req/sec at 100% CPU.  Lighttpd+Fcgi supported 2000 req/sec of the same script at 50% CPU&#8230;</p>
<p>Just my comments here..</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Trophaeum</title>
		<link>http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-12807</link>
		<dc:creator>Trophaeum</dc:creator>
		<pubDate>Sat, 02 Feb 2008 12:31:37 +0000</pubDate>
		<guid isPermaLink="false">http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-12807</guid>
		<description>Sadly it seems as though many of the things posted in these are still things that havn't been tested in a long time. I am yet to find a single issue with apache2 using mod_deflate with IE6 and that includes the fact that its compressing css and js files with it as well... retest things people, there is no permanent perfect solution!

As for fastcgi stability, i have a server sustaining over 120req/sec 24/7 and it's perfectly stable with event mp apache2, php 5.2.5 fastcgi, mod_deflate, xcache, memcached...</description>
		<content:encoded><![CDATA[<p>Sadly it seems as though many of the things posted in these are still things that havn&#8217;t been tested in a long time. I am yet to find a single issue with apache2 using mod_deflate with IE6 and that includes the fact that its compressing css and js files with it as well&#8230; retest things people, there is no permanent perfect solution!</p>
<p>As for fastcgi stability, i have a server sustaining over 120req/sec 24/7 and it&#8217;s perfectly stable with event mp apache2, php 5.2.5 fastcgi, mod_deflate, xcache, memcached&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andrew</title>
		<link>http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-12721</link>
		<dc:creator>Andrew</dc:creator>
		<pubDate>Fri, 01 Feb 2008 12:25:27 +0000</pubDate>
		<guid isPermaLink="false">http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-12721</guid>
		<description>Win XP up to SP1 will exhibit the JavaScript and CSS decompression bugs.  (There are actually several different failure modes.)  One can use the user agent matching of the Apache 2 gzip module to not gzip CSS and JS for those versions of IE6 while still compressing it for the WinXP SP1+ version of IE6.

YMMV, but at this point, about 8% of our traffic is from WinXP pre-SP1 boxes.</description>
		<content:encoded><![CDATA[<p>Win XP up to SP1 will exhibit the JavaScript and CSS decompression bugs.  (There are actually several different failure modes.)  One can use the user agent matching of the Apache 2 gzip module to not gzip CSS and JS for those versions of IE6 while still compressing it for the WinXP SP1+ version of IE6.</p>
<p>YMMV, but at this point, about 8% of our traffic is from WinXP pre-SP1 boxes.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stu</title>
		<link>http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-12717</link>
		<dc:creator>Stu</dc:creator>
		<pubDate>Fri, 01 Feb 2008 10:18:16 +0000</pubDate>
		<guid isPermaLink="false">http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-12717</guid>
		<description>@mike: thanks!

@mibus: I don't recommend FastCGI.  The last time I tested it, it wasn't stable under heavy load.  I'll make a point to look at the different ways to run PHP as part of my Web Platform series.

@gaetano: I've seen the GZIP problem happen with no proxy servers involved :(  I'm hoping that this month's forced upgrade to IE7 will sort out nearly all the remaining copies of IE6 that suffer from this bug.</description>
		<content:encoded><![CDATA[<p>@mike: thanks!</p>
<p>@mibus: I don&#8217;t recommend FastCGI.  The last time I tested it, it wasn&#8217;t stable under heavy load.  I&#8217;ll make a point to look at the different ways to run PHP as part of my Web Platform series.</p>
<p>@gaetano: I&#8217;ve seen the GZIP problem happen with no proxy servers involved <img src='http://blog.stuartherbert.com/php/wp-includes/images/smilies/icon_sad.gif' alt=':(' class='wp-smiley' />  I&#8217;m hoping that this month&#8217;s forced upgrade to IE7 will sort out nearly all the remaining copies of IE6 that suffer from this bug.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: gaetano</title>
		<link>http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-12710</link>
		<dc:creator>gaetano</dc:creator>
		<pubDate>Fri, 01 Feb 2008 09:36:02 +0000</pubDate>
		<guid isPermaLink="false">http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-12710</guid>
		<description>About IE6 and decoding gzipped content: it might be a different issue, but when I have seen it happen the problem was actually introduced by the proxy (MS ISA server) upgrading the browser request from HTTP 1.0 to 1.1 and forgetting to inflate the responses received before passing them back to the browser. IE does not think that http 1.0 responses can be deflated, so he does not reinflate either. The quick workaround was sot set 'use http 1.1 w proxies' on</description>
		<content:encoded><![CDATA[<p>About IE6 and decoding gzipped content: it might be a different issue, but when I have seen it happen the problem was actually introduced by the proxy (MS ISA server) upgrading the browser request from HTTP 1.0 to 1.1 and forgetting to inflate the responses received before passing them back to the browser. IE does not think that http 1.0 responses can be deflated, so he does not reinflate either. The quick workaround was sot set &#8216;use http 1.1 w proxies&#8217; on</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mibus</title>
		<link>http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-12683</link>
		<dc:creator>mibus</dc:creator>
		<pubDate>Fri, 01 Feb 2008 00:36:34 +0000</pubDate>
		<guid isPermaLink="false">http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/#comment-12683</guid>
		<description>I believe you can use the worker MPM with Apache alongside PHP, as long as you're using (eg.) FastCGI rather than mod_php.</description>
		<content:encoded><![CDATA[<p>I believe you can use the worker MPM with Apache alongside PHP, as long as you&#8217;re using (eg.) FastCGI rather than mod_php.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
