<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: How to speed up your ASP.NET web application</title>
	<atom:link href="http://blog.richard.parker.name/2009/08/05/how-to-speed-up-your-asp-net-web-application/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.richard.parker.name/2009/08/05/how-to-speed-up-your-asp-net-web-application/</link>
	<description>Physical computing, the web, usability and tech miscellany</description>
	<lastBuildDate>Wed, 14 Jul 2010 14:45:27 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Neil Fenwick</title>
		<link>http://blog.richard.parker.name/2009/08/05/how-to-speed-up-your-asp-net-web-application/#comment-133</link>
		<dc:creator>Neil Fenwick</dc:creator>
		<pubDate>Thu, 06 Aug 2009 11:17:47 +0000</pubDate>
		<guid isPermaLink="false">http://blog.richard.parker.name/?p=339#comment-133</guid>
		<description>I agree with all the points above.  If I was trying to improve a slow website, I think I&#039;d suggest the following two things:

1. Throw faster hardware at it (assuming you can upgrade).
2. Turn on http / gzip compression of the response.

I prefer the faster hardware because people&#039;s time is expensive, hardware isn&#039;t.  If you&#039;re written slow code, before you spend hours micro-optimising - throw in fast hardware and spend your time on your customers instead.

For me, the pro&#039;s of turning on compression outweight the resource hit on the server. Each http-request is taking up a thread on your server and holding memory and processing time.  Sure, take a hit to compress the page, but then the http-requests are getting in and out quicker, freeing up more resources.  It will at least balance out in the end probably.</description>
		<content:encoded><![CDATA[<p>I agree with all the points above.  If I was trying to improve a slow website, I think I&#8217;d suggest the following two things:</p>
<p>1. Throw faster hardware at it (assuming you can upgrade).<br />
2. Turn on http / gzip compression of the response.</p>
<p>I prefer the faster hardware because people&#8217;s time is expensive, hardware isn&#8217;t.  If you&#8217;re written slow code, before you spend hours micro-optimising &#8211; throw in fast hardware and spend your time on your customers instead.</p>
<p>For me, the pro&#8217;s of turning on compression outweight the resource hit on the server. Each http-request is taking up a thread on your server and holding memory and processing time.  Sure, take a hit to compress the page, but then the http-requests are getting in and out quicker, freeing up more resources.  It will at least balance out in the end probably.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
