Bugzilla

(In reply to Valentin Gosu [:valentin] (he/him) from comment #21)
> > Which makes me wonder if the change to resolve with the canonical flag somehow affected how we report "dns lookup time", but not the actual time to resolve?
> 
> Excellent point, Andrew.
> I think both with TRR and native DNS, what happens here is that the initial DNS lookup prewarms the cache (either the TRR server cache, or the OS cache). We didin't end up using the speculative lookup, but the second lookup ended up completing much faster (it took less time, but it completed later than the first one did).
> 
> I think it's a positive sign that the pageload time didn't regress.


Yes, I think we're getting closer -- this might be an instrumentation issue.

Through glam we can look at the old HTTP_PAGE_* probes recorded in the [loadgroup](https://searchfox.org/mozilla-central/rev/771bc161e016e2bd1f7982a88d387916fdf350dd/netwerk/base/nsLoadGroup.cpp#916-917)

`network_dns_start` doesn't look to have changed:
https://glam.telemetry.mozilla.org/fenix/probe/network_dns_start/explore?ping_type=metrics&timeHorizon=QUARTER

But we can see that `network_dns_end` dropped with your `RESOLVE_CANONICAL_NAME` patch.
https://glam.telemetry.mozilla.org/fenix/probe/network_dns_end/explore?ping_type=metrics&timeHorizon=QUARTER

i.e. this probe recorded the change as an improvement (perhaps just looking at the 2nd dns request, not the "warmed up one"?)

But the pageload event recorded it as a regression, maybe timing from the warm-up start to the final dns resolution?. (recorded from the [timed channel](https://searchfox.org/mozilla-central/rev/771bc161e016e2bd1f7982a88d387916fdf350dd/dom/base/Document.cpp#2182-2214))
But it's still not clear to me how it could end up reporting a longer "end" time.


> We might want to look at the time between asyncOpen -> lookupEnd instead of lookupStart -> lookupEnd (unfortunately not currently captured)

I'll keep looking for something like " asyncOpen -> lookupEnd "

(In reply to Valentin Gosu [:valentin] (he/him) from comment #21)
> > Which makes me wonder if the change to resolve with the canonical flag somehow affected how we report "dns lookup time", but not the actual time to resolve?
> 
> Excellent point, Andrew.
> I think both with TRR and native DNS, what happens here is that the initial DNS lookup prewarms the cache (either the TRR server cache, or the OS cache). We didin't end up using the speculative lookup, but the second lookup ended up completing much faster (it took less time, but it completed later than the first one did).
> 
> I think it's a positive sign that the pageload time didn't regress.


Yes, I think we're getting closer -- this might be an instrumentation issue.

Through glam we can look at the old HTTP_PAGE_* probes recorded in the [loadgroup](https://searchfox.org/mozilla-central/rev/771bc161e016e2bd1f7982a88d387916fdf350dd/netwerk/base/nsLoadGroup.cpp#916-917)

`network_dns_start` doesn't look to have changed:
https://glam.telemetry.mozilla.org/fenix/probe/network_dns_start/explore?ping_type=metrics&timeHorizon=QUARTER

But we can see that `network_dns_end` dropped with your `RESOLVE_CANONICAL_NAME` patch.
https://glam.telemetry.mozilla.org/fenix/probe/network_dns_end/explore?ping_type=metrics&timeHorizon=QUARTER

i.e. this probe recorded the change as an improvement (perhaps just looking at the 2nd dns request, not the "warmed up one"?)

But the pageload event recorded it as a regression, maybe timing from the warm-up start to the final dns resolution? (recorded from the [timed channel](https://searchfox.org/mozilla-central/rev/771bc161e016e2bd1f7982a88d387916fdf350dd/dom/base/Document.cpp#2182-2214))
But it's still not clear to me how it could end up reporting a longer duration (assuming the use of the warmup request was helpful).

> We might want to look at the time between asyncOpen -> lookupEnd instead of lookupStart -> lookupEnd (unfortunately not currently captured)

I'll keep looking for something like " asyncOpen -> lookupEnd "