Chrome Timing View
The image above show chrome spends most of the time queuing up the request. I am trying to figure out why that is happening to minimize it.
According to chrome developer documents:
A request being queued indicates that:
The request was postponed by the rendering engine because it's
considered lower priority than critical resources (such as
scripts/styles). This often happens with images.
The request was put on hold to wait for an unavailable TCP socket that's about to free up.
The request was put on hold because the browser only allows six TCP connections per origin on HTTP 1.
Time spent making disk cache
entries (typically very quick.)
Number 3 seems to be the most likely problem according to chrome developer documents but I know that only one request is going out at a time so that can't be it. I don't think it is number 1 either because the performance monitor doesn't show a lag from rendering. Maybe it is either 2 or 4 but I don't know how to test that.
Chrome Performance Monitor
I've included a picture of the performance monitor that shows these long tasks where something is happening in the system. These are also a mystery to me and seem related.
Any help is greatly appreciated!
Edit: It seems you can disable the disk cache when you open dev tools and that didn't seem to fix the problem.
Related
I have loaded up a database with about 7.5M nodes having 33+M relationships - it's about 25 GB in total. So, it's reasonably large is my point. What I am finding since loading it is that periodically my Neo4j client is just falling over, leaving nothing more than Chrome's irritating "Aw snap - something went wrong" behind. I have checked the logs and found nothing significant there. How can I begin to track down what is happening on these failed queries?
The issue might be with your Chrome environment. This Google support page on the "Aw Snap!" error may be of help.
Also, if your queries return a lot of data or take too long to respond, the browser might be running out of memory or exceeding some internal timeouts. So, make sure the queries you make via a browser are tailored accordingly.
These days I'm evaluating HTTP/2 (on Nginx), as a possible candidate for boosting performance of my application.
I was looking on this nice Akamai HTTP2 demo. From this demo I can see that the "http2" part loads much faster, apparently thanks to HTTP2 multiplexing feature.
So, I decided to look a bit closer. I opened Chrome (version 51) developer tools and examined the Network panel.
I expected to see one single network connection, handling all the requests (e.g. multiplexing).
However, I see multiple connections issued, one per image tile:
Moreover, I see that there is a delay ("stalled") for almost every reques:
I expected that (contrary to HTTP1) all requests will be issued in parallel without delays. Would someone help me to understand what is going on?
What you see are not multiple connections, one per image tile, but multiple requests, one per image tile, on a single TCP connection.
The fact that are multiplexed is evident because there is a large number of requests (tens or even hundreds) that are sent at the same time.
See how the requests are all aligned vertically.
Compare this with a HTTP/1.1 profile and you will see a ladder, ziggurat-style profile because only (typically) 6 requests can be sent at a time. See for example this presentation I gave at 39:54.
What you see is therefore the expected profile for a multiplexed protocol like HTTP/2.
The tiny "stalled" delay that you see for those requests may be due to internal implementation delays (such as queuing) as well as HTTP/2 protocol details such as flow control.
This is a screenshot of Chrome's network timing and I'm trying to figure out the "stalled" time of ~250ms. Google's docs say the stalled status is for time spent either waiting for a socket (possibly due to max 6 rule) or time spent negotiating a proxy. However, in my case, this is the only active request (so it's not a max 6 issue), and there is no other network activity on the computer or even the network. I'm also not using any form of proxy or VPN.
I eventually figured out that this "stalled" time disappears if I change from https to plain http, so at first, I figured this was SSL setup time. But if that were the case, why isn't it showing up in the "SSL" section of the timing?
What's causing this "stalled" time taking 30% of the load time?
Edit
I had my buddy on the opposite coast hit the same page and it's worse for him, which suggests that it could be server-proximity related?
HTTPS
HTTP
I recently found out that Chrome seems to have a connection limit of 6 ( Chrome hangs after certain amount of data transfered - waiting for available socket ) unfortunately I found this out the hard way by getting a "waiting for available sockets" message after loading up too many tabs (7).
I know it is Chrome since another Chrome user (a.k.a another browser session) loads the web page perfectly fine on the same computer at the same time (I have multiple Chrome users open on my computer). So it is not the server in any way.
I believe this is because, in socket.io (which I am using for notifications), I am xhr-polling which is causing Chrome to have to wait until it can grab a socket from one of those connections before it can process the page.
What is the solution to this?
I have thought of a couple of solutions:
make the xhr-polling window smaller, this increases connections in the browser and node.js but will mean the page won't stall.
Use websockets. I am unsure if websockets are immune to this problem either.
Make connections inactive on tabs not focused. Though it seems other sites don't have to do that...
Use some kind of connection sharing. Considering that Chrome isolates websockets and xhr requests to the tab I do find it difficult to understand how that works.
As an added point: the reason I have not gone with websockets from the start is because I use cloudflare. But if this is the way to solve it then: so be it.
Use a real webSocket, rather than XHR Polling. webSocket connections do not count toward the http connection limit to the same origin.
There is a separate global limit to how many webSocket connections can be created, but it is a high number (200 in Firefox - not sure what it is exactly in Chrome).
Here are some references on this topic:
Max parallel http connections in a browser?
Maximum concurrent connections to the same domain for browsers
HTTP simultaneous connections per host limit… are per tab, browser instance or global?.
As far as I know, at the current moment, late 2011 the max-connections-per-server limit remains 6. Please correct me if I am wrong. This is bad that we cannot fix this easily as in Firefox. As far as I know this value is hardcoded.
One of the solutions is to download the Chromium's sources and rebuild them. Is there a more easy solution?
Is there any tricky way to hack this without creating a dozen of mirror-domains?
Why I'm asking the question: My task is to create a html-javascript slideshow that will run inside a fullscreened browser, and a huge monitor is hanging on the wall. The javascript is really complicated, it preloads photos and makes a lot of ajax calls to my web services. If WIFI connection is slow, if 6 photos are loading, the AJAX calls fail, the application runs bad. I want a fast solution based, on http or browser or ubuntu tweak something else, because rebuilding the javascript app will take days.
Offtopic: do you know any other things that can be tweaked in my concrete situation?
IE is even worse with 2 connection per domain limit. But I wouldn't rely on fixing client browsers. Even if you have control over them, browsers like chrome will auto update and a future release might behave differently than you expect. I'd focus on solving the problem within your system design.
Your choices are to:
Load the images in sequence so that only 1 or 2 XHR calls are active at a time (use the success event from the previous image to check if there are more images to download and start the next request).
Use sub-domains like serverA.myphotoserver.com and serverB.myphotoserver.com. Each sub domain will have its own pool for connection limits. This means you could have 2 requests going to 5 different sub-domains if you wanted to. The downfall is that the photos will be cached according to these sub-domains. BTW, these don't need to be "mirror" domains, you can just make additional DNS pointers to the exact same website/server. This means you don't have the headache of administrating many servers, just one server with many DNS records.
I don't know that you can do it in Chrome outside of Windows -- some Googling shows that Chrome (and therefore possibly Chromium) might respond well to a certain registry hack.
However, if you're just looking for a simple solution without modifying your code base, have you considered Firefox? In the about:config you can search for "network.http.max" and there are a few values in there that are definitely worth looking at.
Also, for a device that will not be moving (i.e. it is mounted in a fixed location) you should consider not using Wi-Fi (even a Home-Plug would be a step up as far as latency / stability / dropped connections go).
BTW, HTTP 1/1 specification (RFC2616) suggests no more than 2 connections per server.
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.
There doesn't appear to be an external way to hack the behaviour of the executables.
You could modify the Chrome(ium) executables as this information is obviously compiled in. That approach brings a lot of problems with support and automatic upgrades so you probably want to avoid doing that. You also need to understand how to make the changes to the binaries which is not something most people can pick up in a few days.
If you compile your own browser you are creating a support issue for yourself as you are stuck with a specific revision. If you want to get new features and bug fixes you will have to recompile. All of this involves tracking Chrome development for bugs and build breakages - not something that a web developer should have to do.
I'd follow #BenSwayne's advice for now, but it might be worth thinking about doing some of the work outside of the client (the web browser) and putting it in a background process running on the same or different machines. This process can handle many more connections and you are just responsible for getting the data back from it. Since it is local(ish) you'll get results back quickly even with minimal connections.