Closed Bug 1580431 Opened 4 months ago Closed 2 months ago

Start time, end time of request

Categories

(DevTools :: Netmonitor, enhancement, P3)

enhancement

Tracking

(firefox72 fixed)

RESOLVED FIXED
Firefox 72
Tracking Status
firefox72 --- fixed

People

(Reporter: ruturaj, Assigned: ruturaj)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete, parity-chrome)

Attachments

(5 files, 1 obsolete file)

Attached image chrome-start-time.png

Recently I was debugging some network calls, latency, etc. I found that Firefox misses an essential measurement of the network request (atleast not shown) - that of the start time / timestamp of the network request. Sometimes it is useful to see when the request started (ie. 1.7s into the page hit/refresh, and then at what time it successfully got delivered, ie. 2.3s). This is very helpful when measuring timelines of the page or timed events.

Chrome currently does have the timestamp displayed, it shows the total elapsed time for the request as well. It shows the data at 2 levels

  • The hover card when the mouse is moved over the network timing graph
  • The Timing tab on clicking the request (as in the 1st attachment)

We too should have something similar

  • On the hover state, show in the tooltip (that should suffice)
  • On the clicked state, we already have the Timings tab.

I tried searching in BMO, however couldn't find the bug, so filing it here. I've already checked the developer edition there is no such enhancement in it.

I'm willing to work on this one :)

Thanks for the report!

Yes, agree this looks like useful info to display to the user.

@Harald, any comments for this?

Honza

Priority: -- → P3
Flags: needinfo?(hkirschner)

Absolutely, that there is no way to find out right now makes dependency analysis a lot harder.

We should also file a bug for the hover card if we don't have one yet.

Flags: needinfo?(hkirschner)
Keywords: parity-chrome

Bug for the Hover card : bug 1580493

Honza

No longer blocks: 1580493

Thanks, Honza!
Let me start digging into this.

  • Rutu
Assignee: nobody → ruturaj

Honza,

I have few questions,

  • the Started at ie 1.7s, it should calculated relative to which event? The timings.RESPONSE_COMPLETE.last of the very first request OR the dom.ready event ?
  • How to keep tab of the first request
    • Using a closure of NetworkObserver fn, which could ensure a static like member. The above event will trigger it to be true, and that member's response_complete.last or dom.ready would be considered epoch.
    • Or is there any other place for me too look ?

Rutu

Flags: needinfo?(odvarko)
Attached file WIP: Bug #1580431 (obsolete) —

Added queued at time in TimingsPanel

Attached image wip-queued-at.png

This is a WIP queued at UI

@Ruturaj: there is a dup report of this feature where I was posting detailed instructions how to fix it.

Please look at the following comments:

Honza

Flags: needinfo?(odvarko)

Just adding Honza's comments from bug#1471249


Thanks for the report!

Some instructions for anyone interested in fixing this bug:

The Timings panel is represented by TimingsPanel component and is rendered here
https://searchfox.org/mozilla-central/rev/97976753a21c1731e18177de9e5ce78ea3b3da2d/devtools/client/netmonitor/src/components/TimingsPanel.js#96

All timings data are accessible form props using this.props.request.eventTimings
https://searchfox.org/mozilla-central/rev/97976753a21c1731e18177de9e5ce78ea3b3da2d/devtools/client/netmonitor/src/components/TimingsPanel.js#103

There is also RequestListColumnTime component (used for Timings columns: Start Time, End Time, etc.) showing how to calculate relative times (relative to the first top level document request)
https://searchfox.org/mozilla-central/rev/97976753a21c1731e18177de9e5ce78ea3b3da2d/devtools/client/netmonitor/src/components/RequestListColumnTime.js#54

I believe that queued time corresponds to Blocked time start and Started to Blocked time end.

Honza


We need to calculate two values:

Started - time relative to the first request start time (so, the first request has start time 0)
Queued - time spent in the internal browser queue (the number of concurrent connection is limited so, in case of many requests done by the page some need to wait)

Here is a place showing how we can get the start time of the first request firstRequestStartedMs
https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/devtools/client/netmonitor/src/components/RequestListContent.js#422

We need to implement the same connect method in the TimingsPanel to get the same property
https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/devtools/client/netmonitor/src/components/TimingsPanel.js#167

Don't forget to also update the list of props just like the RequestListContent does
https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/devtools/client/netmonitor/src/components/RequestListContent.js#78

Here is the place in TimingsPanel where we are reading props
https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/devtools/client/netmonitor/src/components/TimingsPanel.js#97

And here is the calculation:

const { eventTimings, totalTime, startedMs } = this.props.request;
const relativeStartedMs = startedMs - this.props.firstRequestStartedMs;
const queuedMs = eventTimings.timings.blocked;

Honza

Attached patch 1580431-1.patchSplinter Review
Attachment #9104586 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Pushed by jodvarko@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/afe9af7c0dd5
Start time, end time relative to first request in the Timings Panel. r=Honza.
Attachment #9104586 - Attachment is obsolete: false
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 72
Flags: needinfo?(odvarko)

Yes, Karen can help with that.

Flags: needinfo?(jswisher)
Keywords: dev-doc-needed

Doc changes are being tracked in https://github.com/mdn/sprints/issues/2469

Flags: needinfo?(jswisher)

Thanks, do let me know how could I be of your help.

Flags: needinfo?(odvarko)
Attachment #9104586 - Attachment is obsolete: true
Regressions: 1601911

Thanks Chris!

You need to log in before you can comment on or make changes to this bug.