<?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: Lazyweb Request: Why would PHP be *faster* than HTML?</title>
	<atom:link href="http://paul-m-jones.com/archives/413/feed" rel="self" type="application/rss+xml" />
	<link>http://paul-m-jones.com/archives/413?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=lazyweb-request-why-would-php-be-faster-than-html</link>
	<description>It&#039;s not enough to be smart; you have to actually know things.</description>
	<lastBuildDate>Wed, 16 May 2012 17:27:27 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1</generator>
	<item>
		<title>By: Code Boy</title>
		<link>http://paul-m-jones.com/archives/413/comment-page-1#comment-423171</link>
		<dc:creator>Code Boy</dc:creator>
		<pubDate>Mon, 19 Mar 2012 17:24:20 +0000</pubDate>
		<guid isPermaLink="false">http://paul-m-jones.com/?p=413#comment-423171</guid>
		<description>I found an article on another blog with &lt;i&gt;opposite&lt;/i&gt; results:

&lt;a href=&quot;http://www.martinsikora.com/load-time-of-static-html-and-dynamic-php-pages&quot; rel=&quot;nofollow&quot;&gt;Load time of static HTML and dynamic PHP pages&lt;/a&gt;</description>
		<content:encoded><![CDATA[<p>I found an article on another blog with <i>opposite</i> results:</p>
<p><a href="http://www.martinsikora.com/load-time-of-static-html-and-dynamic-php-pages" rel="nofollow">Load time of static HTML and dynamic PHP pages</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ?????? ?. ???????</title>
		<link>http://paul-m-jones.com/archives/413/comment-page-1#comment-416033</link>
		<dc:creator>?????? ?. ???????</dc:creator>
		<pubDate>Sat, 22 May 2010 09:18:02 +0000</pubDate>
		<guid isPermaLink="false">http://paul-m-jones.com/?p=413#comment-416033</guid>
		<description>Have you tried different web servers, like nginx or lighttp ?</description>
		<content:encoded><![CDATA[<p>Have you tried different web servers, like nginx or lighttp ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Neil</title>
		<link>http://paul-m-jones.com/archives/413/comment-page-1#comment-414956</link>
		<dc:creator>Neil</dc:creator>
		<pubDate>Fri, 12 Mar 2010 19:21:01 +0000</pubDate>
		<guid isPermaLink="false">http://paul-m-jones.com/?p=413#comment-414956</guid>
		<description>you sure you&#039;re not gzipping output set in your php.ini, while apache isn&#039;t?

That could give php a faster TTLB over straight HTML especially with large streams.</description>
		<content:encoded><![CDATA[<p>you sure you&#8217;re not gzipping output set in your php.ini, while apache isn&#8217;t?</p>
<p>That could give php a faster TTLB over straight HTML especially with large streams.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Schroeder</title>
		<link>http://paul-m-jones.com/archives/413/comment-page-1#comment-414943</link>
		<dc:creator>Jeff Schroeder</dc:creator>
		<pubDate>Fri, 12 Mar 2010 00:12:19 +0000</pubDate>
		<guid isPermaLink="false">http://paul-m-jones.com/?p=413#comment-414943</guid>
		<description>I&#039;m somewhat sceptical of everyone who says something about the disk unless apache does very strange things. In fact, if it is linux I would disagree strongly with what they say. I&#039;m assuming Linux since you said SliceHost.

After reading the file, once, it will be thrown into the Page Cache. So even though it seems logical to think apache reads the html file from disk every single time, in reality it _should_ only read it once assuming the underlying inodes don&#039;t change and the heuristics. After that it should get shoved into the pagecache and any further read(2) calls will in fact hit the page cache from the Linux MM (memory manager).

If apache somehow magically bypasses all of that, the most it would do is call stat(2) which only reads the inode metadata vs the entire file. This is only a somewhat educated guess. Your best bet would be to RTFS but httpd is a gorilla.</description>
		<content:encoded><![CDATA[<p>I&#8217;m somewhat sceptical of everyone who says something about the disk unless apache does very strange things. In fact, if it is linux I would disagree strongly with what they say. I&#8217;m assuming Linux since you said SliceHost.</p>
<p>After reading the file, once, it will be thrown into the Page Cache. So even though it seems logical to think apache reads the html file from disk every single time, in reality it _should_ only read it once assuming the underlying inodes don&#8217;t change and the heuristics. After that it should get shoved into the pagecache and any further read(2) calls will in fact hit the page cache from the Linux MM (memory manager).</p>
<p>If apache somehow magically bypasses all of that, the most it would do is call stat(2) which only reads the inode metadata vs the entire file. This is only a somewhat educated guess. Your best bet would be to RTFS but httpd is a gorilla.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul M. Jones &#187; Blog Archive &#187; Running The Symfony 2 Benchmarks</title>
		<link>http://paul-m-jones.com/archives/413/comment-page-1#comment-414694</link>
		<dc:creator>Paul M. Jones &#187; Blog Archive &#187; Running The Symfony 2 Benchmarks</dc:creator>
		<pubDate>Mon, 22 Feb 2010 01:04:02 +0000</pubDate>
		<guid isPermaLink="false">http://paul-m-jones.com/?p=413#comment-414694</guid>
		<description>[...] is not invoked at all). This indicates something is wrong with the benchmarking environment. I saw similar behavior when using ab (the Apache benchmark tool) and it looks like Siege 2.66 has the same erroneous behavior. [...]</description>
		<content:encoded><![CDATA[<p>[...] is not invoked at all). This indicates something is wrong with the benchmarking environment. I saw similar behavior when using ab (the Apache benchmark tool) and it looks like Siege 2.66 has the same erroneous behavior. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joseph Scott</title>
		<link>http://paul-m-jones.com/archives/413/comment-page-1#comment-410484</link>
		<dc:creator>Joseph Scott</dc:creator>
		<pubDate>Fri, 24 Apr 2009 03:57:30 +0000</pubDate>
		<guid isPermaLink="false">http://paul-m-jones.com/?p=413#comment-410484</guid>
		<description>Late follow up, but thought it might be worth it.

I&#039;ve been running some new tests for WordPress and this time I used Ubuntu instead of FreeBSD as the test server.  In both cases the client running ab was Mac OS X, so that part hasn&#039;t changed.  Both Ubuntu and FreeBSD were running under Parallels.

When I ran the ab tests against the FreeBSD I never saw the problems you described, where the PHP results would magically show up faster that static files.  When I ran these tests against the Ubuntu box though I did!  I was seeing PHP results that were 1.8 times faster than static files, which makes no sense at all.

This makes me wonder if there&#039;s something different that Linux is doing that is causing the wonky numbers.</description>
		<content:encoded><![CDATA[<p>Late follow up, but thought it might be worth it.</p>
<p>I&#8217;ve been running some new tests for WordPress and this time I used Ubuntu instead of FreeBSD as the test server.  In both cases the client running ab was Mac OS X, so that part hasn&#8217;t changed.  Both Ubuntu and FreeBSD were running under Parallels.</p>
<p>When I ran the ab tests against the FreeBSD I never saw the problems you described, where the PHP results would magically show up faster that static files.  When I ran these tests against the Ubuntu box though I did!  I was seeing PHP results that were 1.8 times faster than static files, which makes no sense at all.</p>
<p>This makes me wonder if there&#8217;s something different that Linux is doing that is causing the wonky numbers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Apache Bench &#124; Straylight Run</title>
		<link>http://paul-m-jones.com/archives/413/comment-page-1#comment-410480</link>
		<dc:creator>Apache Bench &#124; Straylight Run</dc:creator>
		<pubDate>Thu, 23 Apr 2009 14:52:17 +0000</pubDate>
		<guid isPermaLink="false">http://paul-m-jones.com/?p=413#comment-410480</guid>
		<description>[...] There have been reports that Apache Bench is not reliable.   SHARETHIS.addEntry({ title: &quot;Apache Bench&quot;, url: [...]</description>
		<content:encoded><![CDATA[<p>[...] There have been reports that Apache Bench is not reliable.   SHARETHIS.addEntry({ title: &#8220;Apache Bench&#8221;, url: [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Harry</title>
		<link>http://paul-m-jones.com/archives/413/comment-page-1#comment-410443</link>
		<dc:creator>Harry</dc:creator>
		<pubDate>Thu, 16 Apr 2009 08:19:42 +0000</pubDate>
		<guid isPermaLink="false">http://paul-m-jones.com/?p=413#comment-410443</guid>
		<description>Hi , dont agree with this php is faster than html ,when tested php and html why the results came html were faster so html is faster than php</description>
		<content:encoded><![CDATA[<p>Hi , dont agree with this php is faster than html ,when tested php and html why the results came html were faster so html is faster than php</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul M. Jones &#187; Blog Archive &#187; A Siege On Benchmarks</title>
		<link>http://paul-m-jones.com/archives/413/comment-page-1#comment-410162</link>
		<dc:creator>Paul M. Jones &#187; Blog Archive &#187; A Siege On Benchmarks</dc:creator>
		<pubDate>Thu, 05 Mar 2009 17:43:48 +0000</pubDate>
		<guid isPermaLink="false">http://paul-m-jones.com/?p=413#comment-410162</guid>
		<description>[...] Paul M. Jones If it&#8217;s worth doing, it&#8217;s worth over-doing.      &#171; Lazyweb Request: Why would PHP be *faster* than HTML? [...]</description>
		<content:encoded><![CDATA[<p>[...] Paul M. Jones If it&#8217;s worth doing, it&#8217;s worth over-doing.      &laquo; Lazyweb Request: Why would PHP be *faster* than HTML? [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: pmjones</title>
		<link>http://paul-m-jones.com/archives/413/comment-page-1#comment-410123</link>
		<dc:creator>pmjones</dc:creator>
		<pubDate>Mon, 23 Feb 2009 13:17:30 +0000</pubDate>
		<guid isPermaLink="false">http://paul-m-jones.com/?p=413#comment-410123</guid>
		<description>Hi Khelo -- I agree with everything you say there.  Let me address point-by-point.

1. I&#039;m not 100% certain that siege is exactly right, but it does seem a lot more reasonable than ab did.  The basis for me saying that is that siege *does not* report HTML being faster than PHP, while ab does.

2. I&#039;m am eager to know why ab is reporting this way, but I don&#039;t know enough about it (or siege) to explain yet.  Happy to take pointers here.

3. Based on my runs with siege so far, the *relative* benchmarking rankings are the same as with ab; the absolute numbers are different, but the percentages are similar, and the ordering of most-to-least responsive remains the same.

I will be publishing updated information as soon as I get it completed; benchmarking is still a very time-consuming task, and I have a paying job I&#039;d like to keep, so it might be a bit.</description>
		<content:encoded><![CDATA[<p>Hi Khelo &#8212; I agree with everything you say there.  Let me address point-by-point.</p>
<p>1. I&#8217;m not 100% certain that siege is exactly right, but it does seem a lot more reasonable than ab did.  The basis for me saying that is that siege *does not* report HTML being faster than PHP, while ab does.</p>
<p>2. I&#8217;m am eager to know why ab is reporting this way, but I don&#8217;t know enough about it (or siege) to explain yet.  Happy to take pointers here.</p>
<p>3. Based on my runs with siege so far, the *relative* benchmarking rankings are the same as with ab; the absolute numbers are different, but the percentages are similar, and the ordering of most-to-least responsive remains the same.</p>
<p>I will be publishing updated information as soon as I get it completed; benchmarking is still a very time-consuming task, and I have a paying job I&#8217;d like to keep, so it might be a bit.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

