<?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"
	>
<channel>
	<title>Comments on: A brief coda on connection management: HTTP 1.0</title>
	<atom:link href="http://www.ajaxperformance.com/2006/12/21/a-brief-coda-on-connection-management-http-10/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.ajaxperformance.com/2006/12/21/a-brief-coda-on-connection-management-http-10/</link>
	<description>A blog by Ryan Breen of Gomez</description>
	<pubDate>Mon, 01 Dec 2008 22:37:50 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: JD</title>
		<link>http://www.ajaxperformance.com/2006/12/21/a-brief-coda-on-connection-management-http-10/#comment-376</link>
		<dc:creator>JD</dc:creator>
		<pubDate>Tue, 23 Jan 2007 17:57:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.ajaxperformance.com/?p=45#comment-376</guid>
		<description>Turning off keepalives for IIS on our dev server caused all the pages except the inital page to fail (almost immediately). Flip the switch back 'on' and the site loads like normal. I will see about the sep. connections (a lot of red tap, within the company to get extra sub domain and within the gov as well). I will keep you updated.</description>
		<content:encoded><![CDATA[<p>Turning off keepalives for IIS on our dev server caused all the pages except the inital page to fail (almost immediately). Flip the switch back &#8216;on&#8217; and the site loads like normal. I will see about the sep. connections (a lot of red tap, within the company to get extra sub domain and within the gov as well). I will keep you updated.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ryan Breen</title>
		<link>http://www.ajaxperformance.com/2006/12/21/a-brief-coda-on-connection-management-http-10/#comment-300</link>
		<dc:creator>Ryan Breen</dc:creator>
		<pubDate>Mon, 22 Jan 2007 23:05:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.ajaxperformance.com/?p=45#comment-300</guid>
		<description>In my previous post, Willy Tarreau had some &lt;a href="http://www.ajaxperformance.com/?p=33#comment-218" rel="nofollow"&gt;interesting feedback&lt;/a&gt; in the comments about an application that sounds somewhat similar to yours but was running on Apache.  In his case, disabling keepalives was quite beneficial because Apache was failing to handle the load from juggling so many concurrent connections.

However, given that your application has a number of small images, a better approach might be to segregate the images onto a separate domain, similar to the &lt;a href="http://www.ajaxperformance.com/?p=33" rel="nofollow"&gt;technique I discussed&lt;/a&gt; in those post.  The image downloads would happen on a different connection pool from your Ajax calls, so it would never be the case that Ajax calls queued up behind 80+ image loads.

I would suggest that you leave keepalives enabled unless you have a strong sense that IIS is choking under the load from the inbound connections.  You can always experiment with leaving keepalives on or off, but separating your content should give you a more predictable and smooth user experience.

Note that, as Georges mentioned in the last article, you will likely need a separate SSL certificate for the images host.  That may or may not be a show stopper for you, but I'm assuming it can be overcome, at least for the purposes of benchmarking performance to see if this approach is worthwhile.

Please let me know what you find in your research.  I am very interested to hear what approach works best for you.

Ryan</description>
		<content:encoded><![CDATA[<p>In my previous post, Willy Tarreau had some <a href="http://www.ajaxperformance.com/?p=33#comment-218" rel="nofollow">interesting feedback</a> in the comments about an application that sounds somewhat similar to yours but was running on Apache.  In his case, disabling keepalives was quite beneficial because Apache was failing to handle the load from juggling so many concurrent connections.</p>
<p>However, given that your application has a number of small images, a better approach might be to segregate the images onto a separate domain, similar to the <a href="http://www.ajaxperformance.com/?p=33" rel="nofollow">technique I discussed</a> in those post.  The image downloads would happen on a different connection pool from your Ajax calls, so it would never be the case that Ajax calls queued up behind 80+ image loads.</p>
<p>I would suggest that you leave keepalives enabled unless you have a strong sense that IIS is choking under the load from the inbound connections.  You can always experiment with leaving keepalives on or off, but separating your content should give you a more predictable and smooth user experience.</p>
<p>Note that, as Georges mentioned in the last article, you will likely need a separate SSL certificate for the images host.  That may or may not be a show stopper for you, but I&#8217;m assuming it can be overcome, at least for the purposes of benchmarking performance to see if this approach is worthwhile.</p>
<p>Please let me know what you find in your research.  I am very interested to hear what approach works best for you.</p>
<p>Ryan</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: JD</title>
		<link>http://www.ajaxperformance.com/2006/12/21/a-brief-coda-on-connection-management-http-10/#comment-284</link>
		<dc:creator>JD</dc:creator>
		<pubDate>Sun, 21 Jan 2007 19:40:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.ajaxperformance.com/?p=45#comment-284</guid>
		<description>I am developing a web based application on a site that uses SSL. The page loads around 80 plus (1-5kb each) static images. Sometimes the app will load images (3 or 4 generally but could be as high as 80+) from the server side as well (they load a lot slower). I noticed you said multiple connections through SSL may not be beneficial (handshaking time and cost per certificate).

I have compressed the 20+ required JavaScript files into 1 file and performed the same with the CSS files. I have turned the interface images, where applicable, into a single tile based image (one image split into peaces with CSS). I will try disabling IIS "keep alive" as well.

The JavaScript and CSS solutions help with the initial load of the page, but it doesn’t solve the 80+ images or the Ajax calls which are qued when waiting for server side images to come down the pipe. I am wondering what you think I should do. Feel free to email if the comments section is not appropriate.</description>
		<content:encoded><![CDATA[<p>I am developing a web based application on a site that uses SSL. The page loads around 80 plus (1-5kb each) static images. Sometimes the app will load images (3 or 4 generally but could be as high as 80+) from the server side as well (they load a lot slower). I noticed you said multiple connections through SSL may not be beneficial (handshaking time and cost per certificate).</p>
<p>I have compressed the 20+ required JavaScript files into 1 file and performed the same with the CSS files. I have turned the interface images, where applicable, into a single tile based image (one image split into peaces with CSS). I will try disabling IIS &#8220;keep alive&#8221; as well.</p>
<p>The JavaScript and CSS solutions help with the initial load of the page, but it doesn’t solve the 80+ images or the Ajax calls which are qued when waiting for server side images to come down the pipe. I am wondering what you think I should do. Feel free to email if the comments section is not appropriate.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.620 seconds -->
