Use Chrome to access the page in https mode, the page loads slow, loading time exceeds 5min,
Accessing the same page  in http mode using  Chrome is faster and no obvious problem.
Use FireFox and IE   (in http and https mode), faster, no obvious problem.

@shivani: Can you take a look at the attached log file?
From a cursory glance I see 20 second waits on ERR_CACHE_LOCK_TIMEOUT.
Thanks!

Yes, it looks like the delay is due to the cache lock since cache lock fix is not in 63. Although not sure what's the reason for the difference in http and https flows. Are the css files being served from the cache in case of http? If that's the case, it might explain why the issue is not there in http.

pywar10ck@gmail.com: Since the cache lock is fixed in M64, could you update the browser to the latest and check if the issue goes away.

we will try m64,and I have a question , if it is the cache lock issue . what is the condition to reproduce it successfully ? what effect that? because a few of our https user meet this issue, a few is not , that really confuse me , thanks !  

Thank you for providing more feedback. Adding requester "mmenke@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

"because a few of our https user meet this issue, a few is not , " is not correct description . the correct description should be a few of our https user delay 5 or 10 minutes , a few only delay 5 to 20 seconds 

Hmm, what about event 2313?
t=209776 [st=   131]     -HTTP_TRANSACTION_SEND_REQUEST
t=209776 [st=   131]     +HTTP_TRANSACTION_READ_HEADERS  [dt=165019]
t=209776 [st=   131]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=165019]
t=374795 [st=165150]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS

please know that , our customer upgrade chrome to 64 , it's not working , the issue still there

Thanks for filing the issue!

@Reporter: Could you please share a sample test file/URL which helps us in triaging the issue in a better way. 

Thanks!

pywar10ck@gmail.com:
Could you also record the net internals with the issue in Chrome 64. Here are the steps to record the net internals:
https://dev.chromium.org/for-testers/providing-network-details

friendly ping, @Reporter:  could you provide the information requested in comments #12 and #13?

Sorry responsed so late, our customer recently send us the log in chrome 64. but they didn't mention if they would provide their URL.so i think i can only provide the log of chrome 64 at this time

Deleted: imc-chrome-net-export-log.rar 14.5 MB

imc-chrome-net-export-log.rar 14.5 MB Download

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

It looks like there was already a slow-loading page opened when net-internals was opened.  Unfortunately, that makes it impossible to tell what was going slowly.  It looks like we both hit the 6-sockets-per-host limit, and the ResourceScheduler delayed a lot of low priority responses until the page body was complete, but I don't think I can tell why without a load that captures the entire page load.

Also, including raw bytes in the log isn't necessary.

do you mean that the log does not include the entire process. do you need me to recollect the log 

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

The log only includes what happens after you start logging, not everything that has happened since you started Chrome (For performance reasons, memory reasons, and privacy reasons).  So you need to start logging, and only then reproduce the issue.  If the issue is also going on in a background tab when you start logging, that will confuse what's going on to the extent of making the log much less useful.

Excuse me. our customer google the problem . and they wanna know something about 6-sockets-per-host , can we relieve this problem by increase the "6" ? , is there any way to modify this " 6-sockets-per-host"?  

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

our customer had recollect the log in chrome 65  . i hope this time it could be working 

Deleted: imc-chrome-net-export-log 2.zip 602 KB

imc-chrome-net-export-log 2.zip 602 KB Download

From the log, it looks like for many of the requests for application.css.jsf, the server took 80 to 90 seconds to respond after we sent our request over the network.  Later, while reading the body, there was also a 40-50 second pause at what looks to be the exact same place in the file, often after a 9404-byte read from the network.

There were two other requests for application.css.jsf - one went quickly, and another didn't have the start delay, but still had the middle-of-body delay.

This looks like a problem with the server, rather than with Chrome, though difficult to be certain.  We did delay other requests while waiting on the CSS file, since CSS blocks layout.

 if this  delay come from the server every browser should be same .
but we test IE and firefox , they have a better performance  . and we test it by chrome on the  server , still have this problem .is there any way to carry on ?

Hello , is there anything could help me carry on locating this issue

Unfortunately, not really - we look to be waiting for data from the server, so it seems to be a server issue.  It could be chrome's network thread is locked up, but I suspect not.  It could be the server is running into issues with Chrome's resource scheduler for some reason, or it doesn't like the behavior of our MIME sniffer.  Or it could be the server sees a Chrome user agent and randomly decides to delay a request for 40 seconds (Admittedly, probably not).  Regardless, without a repro, I don't think this issue is worth investing time investigating, unfortunately.

As per comment #15 and #27 we are unable to triage this issue with out having proper test file.Hence adding TE-NeedsTriageHelp label to this issue for further triage.

Thanks!

Going to close this, per comment #27, I don't think we have any way to make progress here - it doesn't look like a Chrome issue (Though it theoretically could be, certainly), and we can't repro, and don't have any place to start digging, unfortunately.