Monday, March 17th, 2008

IE 8 Connetion Parallelism Issues

Category: Browsers, IE, Performance

Now that we have our hands on IE 8 beta, we see developers testing the various features. Ryan Breen continues IE 8 tests on the new connection limits and parallelism:

A few weeks ago, I discussed IE8’s improved connection parallelism, specifically the increase from 2 concurrent connections per host to 6. One open question was the total number of connections allowed — my speculation was that the IE team would stick with a max of 6 rather than triple that value as well.

I was wrong. The new max is an astonishing 18 concurrent connections (editor: limited to 3 hostnames, you can get more concurrent connections with more hostnames).

This is actually slightly faster than the CNAME trick applied to previous IE versions as it does not incur any hostname resolution cost when establishing the first connections.

Sounds good! However, then Ryan discovered some strange results. When running tests against a dreamhost application there would be some downloads that would be very slow indeed, resulting in worse performance than before. Ryan has a hypothesis:

I suspect that my hosting provider (Dreamhost) simply can’t keep up with the dramatic increase in connection parallelism. 18 connections is simply too much of a good thing, and it will present a scaling problem for those who are on small to medium hosts. 10 users hitting at the same time will yield 180 concurrent connections, a pretty significant number for smaller providers.

Dial-up and cellular network users are also likely to be negatively impacted by this change. In the high broadband world where latency is the dominant factor, greater connection parallelism is a boon. But in bandwidth constrained networks, it just leads to thrash where progress is slowed by all the connections trying to share a small pipe.

I’m curious what sort of testing Microsoft has conducted to determine the impact of this change. The connection parallelism approach is used widely (including by the Virtual Earth team), and some servers may not be ready for the increase. My tests were conducted against only one host, but if similar results are experienced elsewhere, this may fall under the rubric of “don’t break the web.”

Posted by Dion Almaer at 6:14 am
11 Comments

+++--
3.8 rating from 29 votes

11 Comments »

Comments feed TrackBack URI

Good work Ryan. In regards to the excessive connections, I believe IE8 is going to attempt to detect when a slow connection was being used, and go back to the 2 connection limit in those situations.

Comment by kriszyp — March 17, 2008

Excellent work!, and for those who said that this wasn’t a problem in the other post about this, here is the answer! ;-)

Comment by sebasgt — March 17, 2008

Thanks, Kris. I was hoping they were planning a mitigation strategy like that for dial-up users.

Comment by Ryan Breen — March 17, 2008

I wonder if in this situation it would make sense to introduce support for “X-concurrent-connections” header where a host could “suggest” the ideal number of connections. One advantage would be that this could dynamically change with the load on a particular provider (or even be tailored to specific browsers/networks).

Comment by jdsharp — March 17, 2008

IE8’s move is great – 6 connections per hostname, dropped to 2 if dialup. The main point of Ryan’s post is that sites that follow the “CNAME trick”, creating multiple hostnames to increase parallelization, should re-evaluate this strategy. This is especially true if those sites are hosted on servers that can’t handle the load. Users visiting major sites using IE8 likely won’t suffer – those sites can handle the increase in parallel connections. And users visiting smaller sites using IE8 likely won’t suffer either – smaller sites aren’t likely to have implemented the CNAME trick. Only 2 of the top 10 U.S. sites use this technique (YouTube and MSN), so it’s not likely to be widespread on smaller sites.

Comment by souders — March 17, 2008

Thanks, Steve. That’s a great summary of the situation. My motivation for writing this article was to offer a caveat to Ajax developers who have adopted the CNAME approach. Given the interest in articles and presentations on the topic, I suspect there are more than a few smaller sites who have adopted this optimization. I would hate for my small role in publicizing connection parallelism hacks to hurt those early adopters.

Comment by Ryan Breen — March 17, 2008

The idea of a X-concurrent-connections HTTP was the first thing I thought about when I read the article, so I vote for it! I prefer it over sensing the connection bandwidth because I want as much control as possible on my servers.

Comment by pmontrasio — March 17, 2008

This is slightly off topic, but have you noticed some serious css padding issues with IE 8? I’ve noticed a number of places where a site works perfectly in IE7 and all “standards” browsers (Safari, Firefox, Opera) but seems to ignore padding in IE8. I’ve also noticed it’s really slow. Is it just me? I know its a beta, but it doesn’t seem like its even close to being done.

Comment by tazzben — March 17, 2008

I think they should have called this IE8 Alpha-at-best.

Comment by DigitalSkyline — March 17, 2008

I suspect that my hosting provider (Dreamhost) simply can’t keep up…

I’d like to see the same test run with Firefox after setting it to allow the same # of connections. I’m not thoroughly convinced that IE’s increase in concurrency would have that much impact on servers. At this point I’d be more likely to suspect IE’s networking innards than to suggest this change will bring the incredibly mature Apache to its knees with the same # of users.

Comment by mrclay — March 17, 2008

mrclay: My performance testing was not done with IE. I used a third party network testing tool establishing the same number of connections as IE8. I’ve run tests with far higher concurrency with this tool, so I don’t believe client-side factors contribute to the performance differences.

Comment by Ryan Breen — March 17, 2008

Leave a comment

You must be logged in to post a comment.