<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Pushing Apache Performance</title>
	<link>http://lucumr.pocoo.org/cogitations/2007/09/30/pushing-apache-performance/</link>
	<description>Armin Ronacher thinking</description>
	<pubDate>Thu, 28 Aug 2008 02:52:08 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2</generator>

	<item>
		<title>By: Armin Ronacher</title>
		<link>http://lucumr.pocoo.org/cogitations/2007/09/30/pushing-apache-performance/#comment-483</link>
		<author>Armin Ronacher</author>
		<pubDate>Mon, 01 Oct 2007 19:31:34 +0000</pubDate>
		<guid>http://lucumr.pocoo.org/cogitations/2007/09/30/pushing-apache-performance/#comment-483</guid>
		<description>Well, mod_php might be threadsafe to some part if compiled with support for that but before I compile mod_php by hand I use a binary. That has the advantage that apt-get keeps it up to date automatically.

@Paul: I hope I don't forget ;-)</description>
		<content:encoded><![CDATA[<p>Well, mod_php might be threadsafe to some part if compiled with support for that but before I compile mod_php by hand I use a binary. That has the advantage that apt-get keeps it up to date automatically.</p>
<p>@Paul: I hope I don&#8217;t forget ;-)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sapphirecat</title>
		<link>http://lucumr.pocoo.org/cogitations/2007/09/30/pushing-apache-performance/#comment-482</link>
		<author>sapphirecat</author>
		<pubDate>Mon, 01 Oct 2007 17:36:40 +0000</pubDate>
		<guid>http://lucumr.pocoo.org/cogitations/2007/09/30/pushing-apache-performance/#comment-482</guid>
		<description>mod_php most certainly does support threads, but only if it's compiled to do so. Obviously a canned mod_php for prefork won't run with worker, but worker isn't fundamentally incompatible with mod_php. This is what TSRM is all about! (And although TSRM can't protect you if you try to use non-threadsafe C libraries from worker, that's not technically PHP's fault.)</description>
		<content:encoded><![CDATA[<p>mod_php most certainly does support threads, but only if it&#8217;s compiled to do so. Obviously a canned mod_php for prefork won&#8217;t run with worker, but worker isn&#8217;t fundamentally incompatible with mod_php. This is what TSRM is all about! (And although TSRM can&#8217;t protect you if you try to use non-threadsafe C libraries from worker, that&#8217;s not technically PHP&#8217;s fault.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul</title>
		<link>http://lucumr.pocoo.org/cogitations/2007/09/30/pushing-apache-performance/#comment-480</link>
		<author>Paul</author>
		<pubDate>Mon, 01 Oct 2007 10:01:22 +0000</pubDate>
		<guid>http://lucumr.pocoo.org/cogitations/2007/09/30/pushing-apache-performance/#comment-480</guid>
		<description>Hey this may seem like a weird request, but when you switch over to Textpress can you remember to redirect your http://lucumr.pocoo.org/cogitations/feed/atom/ feed as well?</description>
		<content:encoded><![CDATA[<p>Hey this may seem like a weird request, but when you switch over to Textpress can you remember to redirect your <a href="http://lucumr.pocoo.org/cogitations/feed/atom/" rel="nofollow">http://lucumr.pocoo.org/cogitations/feed/atom/</a> feed as well?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Armin Ronacher</title>
		<link>http://lucumr.pocoo.org/cogitations/2007/09/30/pushing-apache-performance/#comment-479</link>
		<author>Armin Ronacher</author>
		<pubDate>Mon, 01 Oct 2007 09:10:51 +0000</pubDate>
		<guid>http://lucumr.pocoo.org/cogitations/2007/09/30/pushing-apache-performance/#comment-479</guid>
		<description>@Graham: I'll come back to that once we run out of resources again :-)
@Alexander: nginx is certainly a good server for static files and I may think about it once the load increases again but for the moment every additional process requires more time to maintain and update it.</description>
		<content:encoded><![CDATA[<p>@Graham: I&#8217;ll come back to that once we run out of resources again :-)<br />
@Alexander: nginx is certainly a good server for static files and I may think about it once the load increases again but for the moment every additional process requires more time to maintain and update it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alexander Solovyov</title>
		<link>http://lucumr.pocoo.org/cogitations/2007/09/30/pushing-apache-performance/#comment-478</link>
		<author>Alexander Solovyov</author>
		<pubDate>Mon, 01 Oct 2007 07:58:41 +0000</pubDate>
		<guid>http://lucumr.pocoo.org/cogitations/2007/09/30/pushing-apache-performance/#comment-478</guid>
		<description>IMHO better way to go is installing of nginx as frontend and serving static images through it. After that you can disable KeepAlive in apache completely.</description>
		<content:encoded><![CDATA[<p>IMHO better way to go is installing of nginx as frontend and serving static images through it. After that you can disable KeepAlive in apache completely.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Graham Dumpleton</title>
		<link>http://lucumr.pocoo.org/cogitations/2007/09/30/pushing-apache-performance/#comment-477</link>
		<author>Graham Dumpleton</author>
		<pubDate>Mon, 01 Oct 2007 04:15:47 +0000</pubDate>
		<guid>http://lucumr.pocoo.org/cogitations/2007/09/30/pushing-apache-performance/#comment-477</guid>
		<description>A further way of reducing what Apache is doing is to turn off logging of requests into the access log altogether. This can be done by not defining CustomLog directive and as far as raw performance goes has more impact than one would expect. Of course, since the bottleneck of web applications is generally elsewhere, eg. database access, in the greater scheme of things the lower overhead may not be noticeable. Although this can help in increasing raw throughput for simple requests and static files, I'm not sure how memory use is affected, so if you did try this would be interested in any feedback.

Now if you like having the access log present so you can gather your own site statistics, one alternative would be to setup all your pages to include tags for Google Analytics and use it to track site usage instead. This way the overhead of tracking site usage is pushed onto the client browser and Google instead, and you aren't wasting your own systems limited resources.

BTW, this only disables logging of requests, any details of exceptional events would still be logged to the error log. Thus, if your Python web applications throw a wobbly, you will still be able to see why. :-)</description>
		<content:encoded><![CDATA[<p>A further way of reducing what Apache is doing is to turn off logging of requests into the access log altogether. This can be done by not defining CustomLog directive and as far as raw performance goes has more impact than one would expect. Of course, since the bottleneck of web applications is generally elsewhere, eg. database access, in the greater scheme of things the lower overhead may not be noticeable. Although this can help in increasing raw throughput for simple requests and static files, I&#8217;m not sure how memory use is affected, so if you did try this would be interested in any feedback.</p>
<p>Now if you like having the access log present so you can gather your own site statistics, one alternative would be to setup all your pages to include tags for Google Analytics and use it to track site usage instead. This way the overhead of tracking site usage is pushed onto the client browser and Google instead, and you aren&#8217;t wasting your own systems limited resources.</p>
<p>BTW, this only disables logging of requests, any details of exceptional events would still be logged to the error log. Thus, if your Python web applications throw a wobbly, you will still be able to see why. :-)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
