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

Issue 829764 link

Starred by 2 users
Status: Assigned
Owner:
arthurso...@chromium.org
Cc:
jam@chromium.org
clamy@chromium.org
arthurso...@chromium.org
█ nasko@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 2
Type: Bug



Sign in to add a comment

Slow Content Download on Chrome

Reported by christop...@gmail.com, Apr 6 2018 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Example URL:
https://jsonplaceholder.typicode.com/photos 

Steps to reproduce the problem:
1. Open the Network tab in Chrome
2. Go to an URL with many json elements like https://jsonplaceholder.typicode.com/photos 
3. Check the Content Download and compare it to a curl/another Browser

What is the expected behavior?
Fast Content Download

What went wrong?
Content Download is way slower than any other major Browser (tests have been run on Firefox 58.0.1 and Microsoft Edge 41.16299.248.0) and seems inconsistent
With browser cache disabled :
Chrome : mostly between 200-400ms 
Firefox : 0ms 
Edge : around 50ms

Did this work before? N/A 

Chrome version: 65.0.3325.181  Channel: stable
OS Version: 10.0
Flash Version: 

We initially had this issue on an internal API where a 460KB Json (gzipped from 3.2MB, but same difference applies without GZip, array of 1k2 json elements) took between 8secs up to 20 on Chrome, while it's below 300ms on other browsers. 
I couldn't find an API replicating the same numbers, but the public API jsonplaceholder also show this issue, although less dramatically.
Please let me know if more specific informations are needed.
Chrome.png
50.7 KB View Download
Firefox.png
27.5 KB View Download
MS Edge.png
37.0 KB View Download
chrome-net-export-log.json
433 KB View Download

Comment 1 by morlovich@chromium.org, Apr 6 2018

Components: UI>Browser>Navigation
So looking at netlog, all the URL_REQUESTS to https://jsonplaceholder.typicode.com/photos
look pretty reasonable, but associated blob: requests (PlzNavigate stream handover stuff?) seem to have hiccups. e.g. event 133438:

t=17962 [st=50]    HTTP_TRANSACTION_READ_BODY  [dt=0]
t=17962 [st=50] -REQUEST_ALIVE

... so 50ms turnaround time for everything, but:

133442: URL_REQUEST
blob:https://jsonplaceholder.typicode.com/9b02315a-52dc-4a3e-9793-620739ded7cc
Start Time: 2018-04-06 05:37:39.182

t=17928 [st=  0] +REQUEST_ALIVE  [dt=398]
                  --> priority = "HIGHEST"
                  --> url = "blob:https://jsonplaceholder.typicode.com/9b02315a-52dc-4a3e-9793-620739ded7cc"
t=17928 [st=  0]    URL_REQUEST_DELEGATE  [dt=0]
t=17928 [st=  0]    URL_REQUEST_START_JOB  [dt=0]
                    --> load_flags = 33026 (BYPASS_CACHE | MAYBE_USER_GESTURE | VERIFY_EV_CERT)
                    --> method = "GET"
                    --> url = "blob:https://jsonplaceholder.typicode.com/9b02315a-52dc-4a3e-9793-620739ded7cc"
t=17928 [st=  0]    URL_REQUEST_DELEGATE  [dt=0]

...
t=17961 [st= 33]    URL_REQUEST_JOB_FILTERED_BYTES_READ
                    --> byte_count = 40
t=18107 [st=179]    URL_REQUEST_JOB_FILTERED_BYTES_READ
                    --> byte_count = 32728
...
t=18326 [st=398]    URL_REQUEST_JOB_FILTERED_BYTES_READ
                    --> byte_count = 7153
t=18326 [st=398] -REQUEST_ALIVE

Comment 2 by krajshree@chromium.org, Apr 8 2018

Labels: Needs-Triage-M65

Comment 3 by arthurso...@chromium.org, Apr 10 2018

Cc: clamy@chromium.org nasko@chromium.org arthurso...@chromium.org
Labels: OS-Linux
Status: Available (was: Unconfirmed)
If this is caused by the the blob url request made for the main resource, this mechanism is going to be removed. If all goes well, it will be enabled at 100% on M66 using finch and the old code path will be removed in M67.
Though, I tried with and without it, I don't see any difference. (See screenshots)
I am using Chrome 67 on refs/heads/master@{#548788}.

I tried this command to benchmark time needed to download the file.
ab -n 50 https://jsonplaceholder.typicode.com/photos
I got a median time of 66ms.
What is weird is that Firefox gives me a total of 9ms and a "receiving time" of 0ms. I expected it to be at least 66ms. I am using Firefox 55 and load the request without using any caches.

So yes, globally I am getting the same results as you do. Maybe we are not displaying the same thing or fail to measure the correct timing.

+CC navigation folks.
with_blob_url_request.png
67.9 KB View Download
without_blob_url_request.png
68.0 KB View Download
firefox.png
41.2 KB View Download

Comment 4 by morlovich@chromium.org, Apr 10 2018 

That may indicate that whatever is pulling the bits is having a hiccup rather than the handover mechanism?

Comment 5 by mmenke@chromium.org, Apr 11 2018

Components: -Internals>Network
Since this appears to be a blob issue, removing the internals>network label.

Comment 6 by arthurso...@chromium.org, Apr 12 2018

Cc: jam@chromium.org
Labels: -Via-Wizard-NetworkDownloading -Needs-Triage-M65
Owner: arthurso...@chromium.org
Status: Assigned (was: Available)
This is not a 'blob' issue. I tested in comment 3 that enabling NavigationMojoResponse (where the blob url mechanism is removed) doesn't improve things.

Assigning this issue to myself for the moment. I will try to debug this once I have more time (not immediately).
►

Sign in to add a comment