Looking at the waterfall and the TCP Dump, it looks like the http requests are issued to WinInet around the same time but the DNS lookups are serialized and it doesn’t process any of the connections until the sequence of DNS lookups completes (which is why the http requests look like they go out on the wire at the same time). It’s actually something I’ve seen before with IE8.
The sequential DNS lookups is not typical for IE8. In other words, it certainly does not always happen in IE8, but apparently sometimes it happens. Question is: what causes the lookups to happen sequentially? You can see in the waterfall further down that other lookups actually take place in parallel…
Note: I believe DNS lookups do always happen sequentially in IE7.
err… i should have filtered : udp.port == 53 to get a clearer picture… my bad.
im very puzzled with the sequential DNS lookups… cant figure out any sane reason for it. DNS doesn’t consume any significant bandwidth… (perhaps its just being IE-ish)
@aaron both IE7 and IE9 handle it well as expected
So… a user 300ms away from DNS server would take seconds to load the javascripts? (testing again with artificial lag)
my previous statement about IE7 was wrong. I should have written: IE7 on Windows XP always does DNS lookups sequentially. Apologies.
Test your page on the Amsterdam IE7 box, that runs on Win XP.
Patrick > can we somehow know what OS is running on each test machine?
FWIW, all of the Dulles browsers except for IE9 are running XP. I’ll see about getting the OS information sent up from the test machines automatically.
Hmm … on this page, the IE7 on Win XP is not doing the lookups sequentially. And so, my blogpost needs an update (luckily, the post is hidden really well
one thing… in most of the examples for the sequential loads… the dns is fired out sequentially… but the all those requests start downloading at around the same time… i.e. the green in the waterfall starts together.
IE initiates the requests for a bunch of files (here: 9)
The first step is DNS lookup (here: 2 at a time)
The second step is setting up the connection.
The third step starts with the actual (GET) request going out, and IE wants to send out these requests all at the same time. In other words, the ‘green’ for object 1 needs to wait for the ‘orange’ of all other objects to finish.
Improved certainly, but not fixed. I’m pretty sure the problem is that something in IE is synchronizing to the main thread so you get a lot of these artificially extended network events. Catchpoint noticed it with other main-thread activities recently: http://blog.catchpoint.com/2011/03/02/newblindspot/ and it’s something I’ve seen with javascript before as well. It MIGHT be possible for me to record the actual DNS and connect times and show gaps after them in the waterfall before the requests in these cases - need to look into it a bit more.
Certainly looks like some low-hanging fruit for the IE team to improve the browser performance though. I should have some experimental chrome support within the next week or so and it will be interesting to see how it compares.