LABjs messing up waterfall charts?

Today i thought I found an issue with LABjs which seemed to effect IE8.

The supposed issue was that there was a delay in start downloading of each javascript file as shown by the waterfall chart see requests #8 to #13.

But when i see the tcp dump in wireshark, and filtering by : http.request.method == "GET"

I see the order is different than in the waterfall chart, and happen very rapidly as expected…

This issue is not seen on IE7 and IE9 test agents… Any pointers?

Sajal,

have you ran tests with other IE8 boxes on Webpagetest.org?
Do they show a different waterfall?

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)

Sajal,

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?

hmm… the amsterdam ie7 box is doing 2 lookups at a time WebPageTest Test - WebPageTest Details better than the Dulles ie8 box at least.

Just read your interesting blogpost about it .

I ran the test again on Dulles IE8 this time using 350ms latency.

It seems with higher latency it is parallelizing(to some extent)?

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 :wink:

[hr]
My original test page now shows inconsistent behavior on the IE7-WinXP box:
http://www.webpagetest.org/result/110228_QW_11d88be203f864e8dccca5cc21432676/

first result at internet explorer 8 sequential dns lookups - Google Search

not exactly well hidden :wink:

Who would actually search for that in Google? My guess: # searches per month < 10

:wink:

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.

Im seeing this sequential lookups more and more now.

See results for msn.com
IE7 : http://www.webpagetest.org/result/110308_EB_f61a380dce1185cccd217bf02b4b320f/
IE8 : http://www.webpagetest.org/result/110308_3T_e3e27a3d3541b5e53c15ff1c44bb2311/

Specifically this region

What are the odds of different servers finishing the initial connection portion at the exact same time?

These requests seems to be dynamically inserted scripts.

Perhaps this is the case:

  • 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.

This can’t be true. Makes no sense.

Whatever the issue is… It seems IE9 fixed it. http://www.webpagetest.org/result/110308_R4_bc9c1f0b764c3824be0fe146256e5942/

I don’t know if I’d go as far as to say “fixed”: http://www.webpagetest.org/result/110308_R4_bc9c1f0b764c3824be0fe146256e5942/1/details/

[attachment=92]

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.