<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: My website is unresponsive, but system load is zero! What&#8217;s going on!</title>
	<atom:link href="http://www.mandible.net/2007/11/30/my-website-is-unresponsive-but-system-load-is-zero-whats-going-on/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mandible.net/2007/11/30/my-website-is-unresponsive-but-system-load-is-zero-whats-going-on/</link>
	<description>Breaking Into the Industry</description>
	<lastBuildDate>Sun, 28 Feb 2010 07:37:08 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Anonymous</title>
		<link>http://www.mandible.net/2007/11/30/my-website-is-unresponsive-but-system-load-is-zero-whats-going-on/comment-page-1/#comment-1050</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Sat, 01 Dec 2007 23:56:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.mandible.net/2007/11/30/my-website-is-unresponsive-but-system-load-is-zero-whats-going-on/#comment-1050</guid>
		<description>Well, there *is* a standardized way for apache to know when something has changed, but you have to add caching headers to your php output, which can be bothersome at first.  In the end, it makes a *lot* of things much faster, though, because the client will cache it as well (IE and Firefox do, anyway).</description>
		<content:encoded><![CDATA[<p>Well, there *is* a standardized way for apache to know when something has changed, but you have to add caching headers to your php output, which can be bothersome at first.  In the end, it makes a *lot* of things much faster, though, because the client will cache it as well (IE and Firefox do, anyway).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Zorba</title>
		<link>http://www.mandible.net/2007/11/30/my-website-is-unresponsive-but-system-load-is-zero-whats-going-on/comment-page-1/#comment-1045</link>
		<dc:creator>Zorba</dc:creator>
		<pubDate>Sat, 01 Dec 2007 04:03:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.mandible.net/2007/11/30/my-website-is-unresponsive-but-system-load-is-zero-whats-going-on/#comment-1045</guid>
		<description>I glossed over some of the details for convenience&#039;s sake. The existence of a central coordination process really doesn&#039;t matter for this application since it wasn&#039;t any sort of a problem (is it ever?) and the various forked processes were reaching their standard memory size pretty much instantly.

Also, you&#039;ll note that I &lt;i&gt;did&lt;/i&gt; say worker mode was 25 threads per process with extra processes for more than that.

I avoided the whole pure-CGI-to-PHP thing just due to speed, and the fact that it&#039;s not really any harder to configure FastCGI (as well as having better and more standard support.) No reason in mentioning a bad solution. And I didn&#039;t bother with apache2 caches for exactly that reason - there&#039;s no way Apache can know when things have changed, so I might as well do it the right way first.

Considering that a lot of this was &quot;let&#039;s see if I can make it run quickly with the hardware I have&quot;, I didn&#039;t really think a separate server was useful. After all, why use two servers when you can just have one? It&#039;d be cheaper for me to just buy twice as much RAM for that one server, anyway, and it&#039;s still nowhere near CPU bound.</description>
		<content:encoded><![CDATA[<p>I glossed over some of the details for convenience&#8217;s sake. The existence of a central coordination process really doesn&#8217;t matter for this application since it wasn&#8217;t any sort of a problem (is it ever?) and the various forked processes were reaching their standard memory size pretty much instantly.</p>
<p>Also, you&#8217;ll note that I <i>did</i> say worker mode was 25 threads per process with extra processes for more than that.</p>
<p>I avoided the whole pure-CGI-to-PHP thing just due to speed, and the fact that it&#8217;s not really any harder to configure FastCGI (as well as having better and more standard support.) No reason in mentioning a bad solution. And I didn&#8217;t bother with apache2 caches for exactly that reason &#8211; there&#8217;s no way Apache can know when things have changed, so I might as well do it the right way first.</p>
<p>Considering that a lot of this was &#8220;let&#8217;s see if I can make it run quickly with the hardware I have&#8221;, I didn&#8217;t really think a separate server was useful. After all, why use two servers when you can just have one? It&#8217;d be cheaper for me to just buy twice as much RAM for that one server, anyway, and it&#8217;s still nowhere near CPU bound.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robin Battey</title>
		<link>http://www.mandible.net/2007/11/30/my-website-is-unresponsive-but-system-load-is-zero-whats-going-on/comment-page-1/#comment-1044</link>
		<dc:creator>Robin Battey</dc:creator>
		<pubDate>Sat, 01 Dec 2007 03:41:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.mandible.net/2007/11/30/my-website-is-unresponsive-but-system-load-is-zero-whats-going-on/#comment-1044</guid>
		<description>Your description of the prefork mode isn&#039;t correct.  There are two details that are very important for your scenario, in both prefork and worker mpms:

1. There is a *single* control process that accepts the connection and hands it off to a spare server.

2. You do *not* keep the processes around forever.  There is a MaxRequestsPerChild directive (default is 10,000) that determines when a client is killed and replaced.  This means that you *don&#039;t* stabilize on the worst-case scenario.  (You might want to reduce your number to something like 100, though.)

Also, in worker mode, you still have a number of processes.  I think there&#039;s typically a max of 25 threads per process by default, but it&#039;s configurable in any case.

You&#039;re right that php isn&#039;t threadsafe yet, so using the worker mpm with mod_php is a bad idea.  However, you can use the worker mpm with a cgi interface to php (there&#039;s a *really* easy way to set this up in debian, contact me if you want more details), that gets around all php threading problems by invoking a separate php interpreter process for each php request.  This is what I use.  FastCGI is even better, of course, because it re-uses the php process, and skips the &quot;load all modules&quot; step with each, but it&#039;s a little more work to set up.

There&#039;s also a few caching options in apache2 itself.  This could alleviate a lot of your CPU problems, but it&#039;s just an RFC2616 (http protocol) compliant cache, and I don&#039;t know how well it plays with wordpress.  I would *definitely* move your mysql server to a different server than your webserver, though.  I use this in front of tomcat applications, to cache all static or near-static content.

Cheers!
-robin</description>
		<content:encoded><![CDATA[<p>Your description of the prefork mode isn&#8217;t correct.  There are two details that are very important for your scenario, in both prefork and worker mpms:</p>
<p>1. There is a *single* control process that accepts the connection and hands it off to a spare server.</p>
<p>2. You do *not* keep the processes around forever.  There is a MaxRequestsPerChild directive (default is 10,000) that determines when a client is killed and replaced.  This means that you *don&#8217;t* stabilize on the worst-case scenario.  (You might want to reduce your number to something like 100, though.)</p>
<p>Also, in worker mode, you still have a number of processes.  I think there&#8217;s typically a max of 25 threads per process by default, but it&#8217;s configurable in any case.</p>
<p>You&#8217;re right that php isn&#8217;t threadsafe yet, so using the worker mpm with mod_php is a bad idea.  However, you can use the worker mpm with a cgi interface to php (there&#8217;s a *really* easy way to set this up in debian, contact me if you want more details), that gets around all php threading problems by invoking a separate php interpreter process for each php request.  This is what I use.  FastCGI is even better, of course, because it re-uses the php process, and skips the &#8220;load all modules&#8221; step with each, but it&#8217;s a little more work to set up.</p>
<p>There&#8217;s also a few caching options in apache2 itself.  This could alleviate a lot of your CPU problems, but it&#8217;s just an RFC2616 (http protocol) compliant cache, and I don&#8217;t know how well it plays with wordpress.  I would *definitely* move your mysql server to a different server than your webserver, though.  I use this in front of tomcat applications, to cache all static or near-static content.</p>
<p>Cheers!<br />
-robin</p>
]]></content:encoded>
	</item>
</channel>
</rss>
