<?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: Web Compression</title>
	<atom:link href="http://blogs.n1zyy.com/n1zyy/2008/05/08/web-compression/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.n1zyy.com/n1zyy/2008/05/08/web-compression/</link>
	<description>A Democrat Living the 2008 New Hampshire Primary</description>
	<lastBuildDate>Thu, 15 Jul 2010 21:22:56 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Matt&#8217;s Blog &#187; Building an Improvised CDN</title>
		<link>http://blogs.n1zyy.com/n1zyy/2008/05/08/web-compression/comment-page-1/#comment-7290</link>
		<dc:creator>Matt&#8217;s Blog &#187; Building an Improvised CDN</dc:creator>
		<pubDate>Tue, 10 Jun 2008 20:46:21 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.n1zyy.com/n1zyy/2008/05/08/web-compression/#comment-7290</guid>
		<description>[...] The other option, and one that may actually be preferable, is to just run the software normally, but stick it behind a cache. This might not be an instant fix, as I&#8217;m guessing the generated pages are tagged to not allow caching, but that can be fixed. (Aside: people seem to love setting huge expiry times for cached data, like having it cached for an hour. The main page here caches data for 30 seconds, which means that, worst case, the backend would be handling two pages a minute. Although if there were a network involved, I might bump it up or add a way to selectively purge pages from the cache.) squid is the most commonly-used one, but I&#8217;ve also heard interesting things about varnish, which was tailor-made for this purpose and is supposed to be a lot more efficient. There&#8217;s also pound, which seems interesting, but doesn&#8217;t cache on its own. varnish doesn&#8217;t yet support gzip compression of pages, which I think would be a major boost in throughput. (Although at the cost of server resources, of course&#8230; Unless you could get it working with a hardware gzip card!) [...]</description>
		<content:encoded><![CDATA[<p>[...] The other option, and one that may actually be preferable, is to just run the software normally, but stick it behind a cache. This might not be an instant fix, as I&#8217;m guessing the generated pages are tagged to not allow caching, but that can be fixed. (Aside: people seem to love setting huge expiry times for cached data, like having it cached for an hour. The main page here caches data for 30 seconds, which means that, worst case, the backend would be handling two pages a minute. Although if there were a network involved, I might bump it up or add a way to selectively purge pages from the cache.) squid is the most commonly-used one, but I&#8217;ve also heard interesting things about varnish, which was tailor-made for this purpose and is supposed to be a lot more efficient. There&#8217;s also pound, which seems interesting, but doesn&#8217;t cache on its own. varnish doesn&#8217;t yet support gzip compression of pages, which I think would be a major boost in throughput. (Although at the cost of server resources, of course&#8230; Unless you could get it working with a hardware gzip card!) [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
