<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Solving Server Performance Nightmares</title>
	<link>http://www.wrevenue.com/2007/12/04/solving-server-performance-nightmares/</link>
	<description>Double Your Site's Revenue - Scott Wainner on Web Business</description>
	<pubDate>Tue, 14 Oct 2008 00:45:11 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3</generator>
		<item>
		<title>By: Dave Starr --- ROI Guy</title>
		<link>http://www.wrevenue.com/2007/12/04/solving-server-performance-nightmares/#comment-999</link>
		<dc:creator>Dave Starr --- ROI Guy</dc:creator>
		<pubDate>Sun, 09 Dec 2007 22:36:42 +0000</pubDate>
		<guid>http://www.wrevenue.com/2007/12/04/solving-server-performance-nightmares/#comment-999</guid>
		<description>Very good tips, Scott.  As someone who has been around computers since long before the Web I am amazed/appalled by the level of service that even "big name" sites still acceot as "ok".  Servers do not have to crump when a blog page gets "Digged" and data centers (if their data architect ever had a cogent thought) do not have to shut down whole banks of servers to change a network switch.  We (bloggers,site developers, users, hosting providers, et al,) should demand better of ourselves and our industry.

I really liked the round-robin with failover idea.  Seems to me that even a small-time hosting provider could partner with s couple other small competitors and offer near-perfect web page avaiolability (up time) for very little cost.</description>
		<content:encoded><![CDATA[<p>Very good tips, Scott.  As someone who has been around computers since long before the Web I am amazed/appalled by the level of service that even &#8220;big name&#8221; sites still acceot as &#8220;ok&#8221;.  Servers do not have to crump when a blog page gets &#8220;Digged&#8221; and data centers (if their data architect ever had a cogent thought) do not have to shut down whole banks of servers to change a network switch.  We (bloggers,site developers, users, hosting providers, et al,) should demand better of ourselves and our industry.</p>
<p>I really liked the round-robin with failover idea.  Seems to me that even a small-time hosting provider could partner with s couple other small competitors and offer near-perfect web page avaiolability (up time) for very little cost.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott</title>
		<link>http://www.wrevenue.com/2007/12/04/solving-server-performance-nightmares/#comment-913</link>
		<dc:creator>Scott</dc:creator>
		<pubDate>Tue, 04 Dec 2007 15:25:41 +0000</pubDate>
		<guid>http://www.wrevenue.com/2007/12/04/solving-server-performance-nightmares/#comment-913</guid>
		<description>I've had success with a lean compile of Apache Worker for true static content like html pages and images.  For threaded &#038; dynamic content, Apache is a necessity, and my point was just that a static page serves up with much less memory and CPU overhead than a dynamic page.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve had success with a lean compile of Apache Worker for true static content like html pages and images.  For threaded &#038; dynamic content, Apache is a necessity, and my point was just that a static page serves up with much less memory and CPU overhead than a dynamic page.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tom Printy</title>
		<link>http://www.wrevenue.com/2007/12/04/solving-server-performance-nightmares/#comment-911</link>
		<dc:creator>Tom Printy</dc:creator>
		<pubDate>Tue, 04 Dec 2007 14:35:50 +0000</pubDate>
		<guid>http://www.wrevenue.com/2007/12/04/solving-server-performance-nightmares/#comment-911</guid>
		<description>Caching content that is generated via script can be a huge saver. A better caching method may be to use &lt;a href="http://www.danga.com/memcached/" rel="nofollow"&gt;memcache&lt;/a&gt;.  Unlike cache lite that uses the filesystem memcache is memory resident. Anything you cache is stored in the systems memory. This can be many times faster since the disk is taken out of the performance equation.  The down side is that you have to be able to install services on the server that you are hosting your website on.</description>
		<content:encoded><![CDATA[<p>Caching content that is generated via script can be a huge saver. A better caching method may be to use <a href="http://www.danga.com/memcached/" rel="nofollow">memcache</a>.  Unlike cache lite that uses the filesystem memcache is memory resident. Anything you cache is stored in the systems memory. This can be many times faster since the disk is taken out of the performance equation.  The down side is that you have to be able to install services on the server that you are hosting your website on.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Yang</title>
		<link>http://www.wrevenue.com/2007/12/04/solving-server-performance-nightmares/#comment-907</link>
		<dc:creator>Scott Yang</dc:creator>
		<pubDate>Tue, 04 Dec 2007 09:34:59 +0000</pubDate>
		<guid>http://www.wrevenue.com/2007/12/04/solving-server-performance-nightmares/#comment-907</guid>
		<description>"Apache is great at serving static content..."

Actually Apache is *crap* at serving static content as each static file request requires a full Apache instance, loaded with mod_php and other memory-hungry modules, to send back the content to the browser.

A better solution is to put a light weight web server (lighttpd/nginx/litespeed) at the front to serve static content, and then either proxy to Apache for dynamic content, or use PHP/FastCGI. This way you'll use much less memory, which can be by memcache to cache content or MySQL to cache query results.</description>
		<content:encoded><![CDATA[<p>&#8220;Apache is great at serving static content&#8230;&#8221;</p>
<p>Actually Apache is *crap* at serving static content as each static file request requires a full Apache instance, loaded with mod_php and other memory-hungry modules, to send back the content to the browser.</p>
<p>A better solution is to put a light weight web server (lighttpd/nginx/litespeed) at the front to serve static content, and then either proxy to Apache for dynamic content, or use PHP/FastCGI. This way you&#8217;ll use much less memory, which can be by memcache to cache content or MySQL to cache query results.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: PHP Coding School &#187; Blog Archive &#187; php code [2007-12-04 07:53:40]</title>
		<link>http://www.wrevenue.com/2007/12/04/solving-server-performance-nightmares/#comment-906</link>
		<dc:creator>PHP Coding School &#187; Blog Archive &#187; php code [2007-12-04 07:53:40]</dc:creator>
		<pubDate>Tue, 04 Dec 2007 09:01:34 +0000</pubDate>
		<guid>http://www.wrevenue.com/2007/12/04/solving-server-performance-nightmares/#comment-906</guid>
		<description>[...]  Solving Server Performance Nightmares  By Scott  For all other PHP scripts, you&#8217;ll need some coding savvy or a good programmer to implement it, but PHP Cache Lite is a relatively simple way to cache dynamic pages. With cache lite, you simply add some code to the top of the script that &#8230;   W Revenue dot Com - http://www.wrevenue.com [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;]  Solving Server Performance Nightmares  By Scott  For all other PHP scripts, you&#8217;ll need some coding savvy or a good programmer to implement it, but PHP Cache Lite is a relatively simple way to cache dynamic pages. With cache lite, you simply add some code to the top of the script that &#8230;   W Revenue dot Com - <a href="http://www.wrevenue.com" rel="nofollow">http://www.wrevenue.com</a> [&#8230;]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
