5

I'm seeing some strange behavior from Chrome when loading web resources from a Jetty 9.2.3 instance I'm setting up. In particular, I see some requests returning quickly, while others take a very long time, with Chrome reporting the time to be 'blocking'.

enter image description here

https://stackoverflow.com/questions/10537399/what-does-the-times-mean-in-google-chromes-timeline-in-the-network-panel suggests that 'blocking' is effectively the local browser running slowly due to local resource limits, however this doesn't happen with other web servers, and does not happen from different client machines. Firefox seems to exhibit the same slowness from time time time (though doesn't specify where the time went), while curl seems to always respond quickly

Presumably it's somehow related to how I've configured Jetty, but I'm stuck for how to look into it further.

How can I track down the cause of this issue?

Community
  • 1
Matt Sheppard
  • 1,559
  • 2
  • 11
  • 10
  • You need to look at the whole timer waterfall. When the request you're looking at is blocked other requests (a finite number, depending on which browser and its config) are being processed - if there are too many requests in parallel, it's FIFO to process the queue. It likely has very little to do with how you've configured Jetty - you're looking at purely client-side problem. – AD7six Nov 04 '14 at 19:01
  • Is Chrome on that client configured to use a proxy? https://developer.chrome.com/devtools/docs/network#about_the_resource_timing_api says that "blocking" includes time spent in proxy negotiation. – Paul Haldane Nov 04 '14 at 23:43
  • There isn't a proxy configured, but that link is very useful. I wonder if Jetty is somehow not closing the connection such that Chrome doesn't want to reuse it until some timeout has occurred. – Matt Sheppard Nov 05 '14 at 22:25
  • Any update ? I encountered the same problem. – Jerry Chin Jun 02 '17 at 06:36
  • Sorry - not really. I solved the problem in my environment somehow as a side effect of rewriting how we ran jetty (from invoking it with a bunch of xml file configuration to setting it up with some java code that embedded jetty). Unfortunately, that leaves me none the wiser as to the underlying problem though. Would love to know if you do solve it @JerryChin. – Matt Sheppard Jun 04 '17 at 07:53
  • Another edge case is if multiple requests have the same URL, Chrome and Firefox (but not IE) will block (Chrome now shows this as "Stalled" on the timeline) until the first completes due to interaction with the caching subsystem. If you're trying to test something with concurrent requests, just append a different URL parameter to get past this. – Nathan Williams Oct 11 '17 at 15:53

0 Answers0