New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 881588 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 5
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

In devtools, discrepancy in HAR receive timing vs network tab

Reported by kenpoley...@gmail.com, Sep 6

Issue description

Chrome Version       : 69.0.3497.81
OS Version: OS X 10.12.6
URLs (if applicable) :
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari: N/A
    Firefox: N/A
    IE/Edge: N/A

What steps will reproduce the problem?
1. (optional) Write devtools extension code that displays request.timings.receive for an asset
2. Hit a web page with images
3. Copy the HAR from the net tab, examine results from the extension, examine the Net tab, compare them for an image asset.

What is the expected result?

request.timings.receive should match "Content Download" time in the Timing tab in the network request detail. The HAR matches request.timings.receive.

What happens instead of that?

For SOME assets (not all) request.timings.receive appears to include the Queueing time along with the content download time. In my testing, this seemed to occur on JPG images, but not on text files. For text files I looked at request.timings.receive matched the Content Download number. 

Please provide any additional information below. Attach a screenshot if
possible. I'll attach a screenshot showing the net tab/Timings, and another showing a spreadsheet with the output from the extension.  Here is a snipped portion of the har for that resource (headers and cookies redacted):

{
	"startedDateTime": "2018-09-06T21:50:01.129Z",
	"time": 582.291177001287,
	"request": {
	  "method": "GET",
	  "url": "https://www.ballarddesigns.com/wcsstore/images/BallardDesigns/espots/2018/ma18/nav-banners/021618_MA18_Nav_espot_sunbrella.jpg",
	  "httpVersion": "HTTP/1.1",
	  "headers": [...],
	  "queryString": [],
	  "cookies": [...],
	  "headersSize": 3009,
	  "bodySize": 0
	},
	"response": {
	  "status": 200,
	  "statusText": "OK",
	  "httpVersion": "HTTP/1.1",
	  "headers": [...],
	  "cookies": [],
	  "content": {
		"size": 19129,
		"mimeType": "image/jpeg",
		"compression": 0
	  },
	  "redirectURL": "",
	  "headersSize": 1916,
	  "bodySize": 19129,
	  "_transferSize": 21045
	},
	"cache": {},
	"timings": {
	  "blocked": 31.711177000002703,
	  "dns": -1,
	  "ssl": -1,
	  "connect": -1,
	  "send": 0.07900000000000063,
	  "wait": 60.74399999827426,
	  "receive": 489.75700000301003,
	  "_blocked_queueing": 487.1770000027027
	},
	"serverIPAddress": "127.0.0.1",
	"connection": "118867",
	"pageref": "page_14"
}      

Note the receive time of 489.757, which matches request.timings.receive in the spreadsheet screenshot, but does not match "Content Download" (2.58) in the net tab screenshot.

Also, note that this equation from W3C HAR spec would not be satisfied with the data in the above HAR:

entry.time == entry.timings.blocked + entry.timings.dns +
    entry.timings.connect + entry.timings.send + entry.timings.wait +
    entry.timings.receive;

though if you exclude "_blocked_queueing" it does match, indicating that it is doubly included (my theory being that it is incorrectly included in the receive number).

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36



 
Screen Shot 2018-09-06 at 5.54.09 PM.png
58.6 KB View Download
Screen Shot 2018-09-06 at 5.53.09 PM.png
40.1 KB View Download
Labels: Needs-Triage-M69
Cc: krajshree@chromium.org
Components: Platform>DevTools
Labels: Needs-Feedback Triaged-ET
kenpoleyeff@ - Thanks for filing the issue...!!

Could you please provide a sample extension file/url to test the issue from TE-end.
This will help us in triaging the issue further.

Thanks...!!
You can see the behavior by just looking at the HAR file. But I'll attach the extension anyhow. It's pretty crude right now...

It adds a Performance Export tab to devtools. While loading a page, the HAR data populates the textarea. When the load completes, you can hit the Copy button and paste it into a spreadsheet.
perfExport.zip
5.9 KB Download
Project Member

Comment 4 by sheriffbot@chromium.org, Sep 11

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: Needs-Feedback
Tried testing the issue on chrome reported version# 69.0.3497.81 using Mac 10.12.6 with steps mentioned below:
1) Launched chrome reported version and installed the extension provided in comment# 3 from Chrome://extensions
2) Able to see "Performance Export" tab in the Devtools, Opened Devtools > Performance Export tab and loaded the page having the page(URL: https://www.ballarddesigns.com/wcsstore/images/BallardDesigns/espots/2018/ma18/nav-banners/021618_MA18_Nav_espot_sunbrella.jpg)
3) Able to see data generated in the Performance Export tab
4) As mentioned in comment# 0, steps to reproduce the problem, didn't get how to copy HAR from net tab

@Reporter: Please find the attached screencast for your reference and let us know if we missed anything in reproducing the issue, provide your feedback on it which in further triaging it. If possible could you please provide screencast of the issue which help in better understanding.

Thanks!
881588.mp4
2.5 MB View Download
Owner: jarhar@chromium.org
Status: Assigned (was: Unconfirmed)
Components: -Platform>DevTools Platform>DevTools>Network
There should be a "Copy" button below the big text area in the Performance Export tab. If it is not showing up, you can copy it your selffrom the textarea and paste it in a spreadsheet, though you won't have the benefit of column headings. Receive time is the 6th column.

But, you don't need to use the extension at all. You can see the same data in the HAR. Go into the Net tab, right click anywhere in the list and select Copy -> Copy All as HAR. You'll then need to paste that into a text editor to read. (The whole point of the extension was to make it easy to paste the HAR data into a spreadsheet.)
Project Member

Comment 9 by bugdroid1@chromium.org, Oct 5

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/78aa7084ffcdeec8b4576892a34a626248cb0ad5

commit 78aa7084ffcdeec8b4576892a34a626248cb0ad5
Author: Joey Arhar <jarhar@chromium.org>
Date: Fri Oct 05 00:09:57 2018

[DevTools] Correct timings.receive in HAR exports

receiveEnd is supposed to be relative to requestTime like waitEnd, and
since it was relative to issueTime, having a long queueing time for a
request would cause timings.receive to be unreasonably large. Changing
it to this also makes it match up with the "Content Download" value in
the Timing panel of the request.

Bug:  881588 
Change-Id: Ib7101b2be6be845464c48958a9b3ad716227844a
Reviewed-on: https://chromium-review.googlesource.com/c/1262875
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596934}
[modify] https://crrev.com/78aa7084ffcdeec8b4576892a34a626248cb0ad5/third_party/WebKit/LayoutTests/http/tests/devtools/resource-har-headers-expected.txt
[modify] https://crrev.com/78aa7084ffcdeec8b4576892a34a626248cb0ad5/third_party/blink/renderer/devtools/front_end/sdk/HARLog.js

Status: Fixed (was: Assigned)
Thank you!

Sign in to add a comment