Incorrect timings in net panel?

[Adrian Yee]

Hi,

I'm running into an issue with the Firebug net panel giving what seems
to be incorrect timings. What seems to be happening is that places
where it seems that it's blocking, it's showing it as DNS requests.
It's best shown in an example:

http://gtmetrix.com/reports/www.thestudentroom.co.uk/x6PUgJMn/harviewer?url=http://gtmetrix.com/reports/www.thestudentroom.co.uk/x6PUgJMn/net.harp&expand=true

All the requests to static.thestudentroom.co.uk look like they're
blocking from the connection limit, but they show up as DNS lookups.

However, blocking connections do work, for example, using cuzillion:

http://gtmetrix.com/reports/stevesouders.com/qJFG9jpO/harviewer?url=http://gtmetrix.com/reports/stevesouders.com/qJFG9jpO/net.harp&expand=true

correctly shows the last 2 connections as blocking, but then the DNS
lookup time looks a little high. Even if we retest (where the DNS
request should be cached), it still shows a 544ms time for the DNS lookup.

GTmetrix currently uses:

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.10)
Gecko/20100914 Firefox/3.6.10
Firebug 1.5.4
NetExport 0.8b8

Though I have also tested on:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12)
Gecko/20101026 Firefox/3.6.12
Firebug 1.5.4

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100920
Gentoo Firefox/3.6.9
Firebug 1.7X.0a4

Adrian

[Adrian Yee]

Any input on this one Honza? Thanks!

Adrian

[Honza (Jan Odvarko)]

As far as the Cuzillion example is concerned, the first 6 images
shouldn't block at all (if max connections is set to 6) so it doesn't
look to me that the DNS resolution is displayed instead of the
blocking time.


I tried the Cuzillion example again and got following results:
http://www.softwareishard.com/har/viewer/?inputUrl=http://www.softwareishard.com/temp/har/stevesouders.com.harp

It's different there is not DNS resolution (it's already in my cache),
but it's visible that the connection took some time to create first 6
connections (for the first 6 requests). And the last two requests
reused an existing connection.

I tried also the http://www.thestudentroom.co.uk/ example.
http://www.softwareishard.com/har/viewer/?inputUrl=http://www.softwareishard.com/temp/har/www.thestudentroom.co.uk.harp

But it's too complex to say there is a bug.

Anyway, not sure how to properly test/debug the DNS connection time.
Do you have any solid examples that have predicted behavior?

Honza

On Nov 18, 10:22 pm, Adrian Yee <adr...@gt.net> wrote:
> Any input on this one Honza?  Thanks!
>
> Adrian
>
> On 10/29/10 12:40, Adrian Yee wrote:
>
> > Hi,
>
> > I'm running into an issue with the Firebugnetpanelgiving what seems

> > to beincorrecttimings. What seems to be happening is that places where

> > it seems that it's blocking, it's showing it as DNS requests. It's best
> > shown in an example:
>

> >http://gtmetrix.com/reports/www.thestudentroom.co.uk/x6PUgJMn/harview...

>
> > All the requests to static.thestudentroom.co.uk look like they're
> > blocking from the connection limit, but they show up as DNS lookups.
>
> > However, blocking connections do work, for example, using cuzillion:
>

> >http://gtmetrix.com/reports/stevesouders.com/qJFG9jpO/harviewer?url=h...

[Adrian Yee]

Hi Honza,

I wasn't really saying that the Cuzillion example should have been
blocking, just remarking that the DNS time seemed to be a bit long. I
mentioned the Cuzillion example to show that blocking was working properly.

Anyways, I have stripped out some of the contents of the page to get a
smaller waterfall that only makes requests from that single domain:

http://devrandom.com/test/tsr.html

http://gtmetrix.com/reports/devrandom.com/mlsJRa6W/harviewer?url=http://gtmetrix.com/reports/devrandom.com/mlsJRa6W/net.harp&expand=true

This HAR was generated with the DNS already in cache, so I don't think
any of the requests should have any DNS time. Also notice the 3rd last
request doesn't have and DNS time, while the rest do.

At first from the previous waterfalls, I thought it might be that
requests that had queued but the DNS hadn't been resolved yet would have
the blocking time added to the DNS time incorrectly, but from this
waterfall, this doesn't look like that's the case.

Thanks for looking into this.

Adrian