Issue metadata
Sign in to add a comment
|
Long Content Download times with high CPU usage
Reported by
bme...@gmail.com,
May 17 2018
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36 Steps to reproduce the problem: Reproducing this one is difficult as it involves interacting with our application. We are running a long poll for 'events' and as events are found on the server, we apply updates to the client (both DOM updates and JavaScript object updates). The issue happens more frequently when we have a high CPU load on the machine and we do not have the Chrome tab in focus and if events are coming in frequently (less than 10 seconds per event). What is the expected behavior? Our application makes use of a 5 second long poll to pull down events and apply them to the UI. We expect that poll to take ~5 seconds max and then download the response from the server. Once the response it received, it should apply any necessary updates to the screen. What went wrong? We are seeing the 'Content Download' taking much longer than expected. Its normal time should be negligible (26ms in one example) however in this case its taking upwards of 6 seconds. We've seen that balloon up to as much as 30 seconds. As a result, the client falls behind. Did this work before? Yes It worked last year between 6/7/2017 and 6/10/2017 Chrome version: 66.0.3359.181 Channel: stable OS Version: 10.0 Flash Version: There is a lot of JavaScript being processed for this application and its currently in its 4th year of use and in the process of being sunset, this year will be the last time we use it. That being said, we have not seen this behavior before in Chrome (and it is working fine in Firefox). I have multiple performance profiles which are too big to attach showing both the app working and not working.
,
May 18 2018
,
May 18 2018
This seems to be related to scheduling of background tabs.
,
May 21 2018
Unable to test this issue from TE end unless we have a sample file /URL. Could someone from Blink>Scheduling team please look at attached Performance Profiles. @Reporter: Please provide sample test file to test this issue from TE end. Thanks!
,
May 21 2018
I attached the payload which is being downloaded. We can't provide access to the application as its internal and not for public consumption. Also, we do still see this happening even when Chrome is in focus and the application is the main tab. When chrome is not in focus the problem seems to be worse.
,
May 21 2018
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
,
May 24 2018
As per comment #5, this issue can't be triaged from our end as we don't have access to it, Hence adding TE-NeedsTriageHelp label for further triaging of the issue. Thanks.! |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by perry.pi...@mlb.com
, May 17 2018