azhar.salati@ Can you please elaborate how you are seeing the "pending" state of the requests?

I am seeing the "pending" state of the requests in the Network tab of the Developer tools.
The requests are going into pending state for several minutes and actual time taken by the requests to complete is very less(in ms).
The requests are there in pending state for more than a 1 minute and once the requests are shown as completed the actual time shown in the Network tab for that request is shown in milliseconds.
I have attached two screen shots which shows the pending state of the request.
Inside RequestPendingState.png - You can see the pending request. They remain in the pending state for 2.5 minnutes.
Inside AfterRequestComplete.png - You can see the request are in completed state and the actual time taken for the request are in (142 ms, 330 ms, 355 ms)

If the request are taking time in ms to complete why are they going into pending  state for more than 2 minutes.

Deleted: RequestPendingState.png 65.0 KB

	RequestPendingState.png 65.0 KB View Download

Deleted: AfterRequestComplete.PNG 40.5 KB

	AfterRequestComplete.PNG 40.5 KB View Download

azhar.salati@: I'm trying to correlate the screenshots with the net-internals dump; were they from the same instance of this problem?  The logging in the net-internals dump makes it look like the highlighted requests didn't take very long.  Before I dive into this, I just wanted to confirm that both screenshots and n-i dump were from the same instance of the problem?

Also, might you be willing to record a trace of the problem?  Bring up "about:tracing", click Recover, Click "Edit cateogories" and make sure all of the following categories are enabled:

blink.net
devtools.timeline
loading
loader
net
netlog

That'll help us figure out where the delay is, if it's not in the network stack.

Sorry, to continue the instructions in the last comment: Do the above, then click "Record", then reproduce the problem, then click "Stop" on the record tab, then click "Save", and attach the result to this issue (or send it to me if it's too big to attach).  Thanks ...

Oh "blink" is also an important category to include.

rdsmith@ Sorry for the inconvenience as the attached net logs and screen shot of the network tab were of different instances.
Now i have collected the net-logs again and also i have created the tracing report.

I have attached both the things. Please get the required tracing report and the net logs.

Deleted: trace_tracing_output.json.gz 1.8 MB

trace_tracing_output.json.gz 1.8 MB Download

Deleted: net-internals-log.json 10.3 MB

net-internals-log.json 10.3 MB View Download

wow there are a lot of requests here, so much so that I think we're looking at something like issue 655585.

There's also a JS function that takes 38s to execute, onLoadFn from bootstrap.js, much of that time is spent GC thrashing (likely due to the thousand or so resource requests).

You say this works for 64 bit Chrome, could you post an identical trace from that version?

csharrison@ Thanks for the quick updates!

There are lot of requests right now made for loading the application and i know the number of request that are made is very big which is not a good situation.
The reason for this is the application for which i am sharing the details is running in development mode but in production we are creating a package where all the javascript resources are bundled and minimized into a single js file.
But even if the resources request count is less on the production environment, this issue still exists for 32 bit chrome and not on 64 bit chrome.
So i think more number of resource request may not be the problem here.

Yes the application runs as expected on 64 bit Chrome, so as requested i am attaching the identical trace from the same application instance which is captured using 64 bit Chrome having version as 54.0.2840.99 m (64-bit).

Please get the required trace reports.

Deleted: trace_chrome_64bit_tracing_report.json.gz 4.2 MB

trace_chrome_64bit_tracing_report.json.gz 4.2 MB Download

Deleted: net-internals-log_64bit.json 9.3 MB

net-internals-log_64bit.json 9.3 MB View Download

The main difference is the monster function call I mentioned earlier. It takes almost 40s on the original trace, which blocks requests from finishing on the main thread.

In the new trace there is another heavy function (coming from Ready.js) but it only takes ~2s to execute. I'm not sure why we're seeing a big difference here.

Thank you for providing more feedback. Adding requester "shivanisha@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

-shivanisha

To me it looks like this is almost completely explained by slower JS execution blocking the main thread. Issue 655585 is certainly causing problems as well but it's limited to 20s, not minutes.

Blink's main thread is just completely busy executing JS in the trace_tracing_output you logged. I don't think there's anything we can do here.

Are these traces from the same device?

azhar.salati:  Are you still running into those issue?  Could you response to csharrison's question in comment 15?

Closing for now, feel free to file a bug again if you're still running into these issues.