There is a web page that after sending a POST request many database transactions take place lasting a significant amount of time.
When clicking to post data, a spinning wheel appears with JS.
Users (of Chrome) complain that the response does not appear and that the whell keeps spinning forever.
I would expect that a connection timeout occurs after 300secs, but wouldn't this generate an error code view in Chrome instead of just keeping the previous view?
Additionally, in case this is indeed a connection timeout, is there any way from server side to keep Chrome waiting after 300secs?
Thank you for your time!
Related
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.
I have an application in which I open a websocket from a browser (Chrome, in my case) to a server, then I start sending messages from the server side to the browser. What I am finding is that when I send messages too quickly from the server, messages start getting buffered up on the browser side. This means that the browser "falls behind" and ends up processing messages sent long ago by the server, which in my application is undesirable.
I have eliminated the following possible candidates for where this buffering is happening:
The server. I can kill the server process entirely and I see that messages continue to be received by my javascript code for several minutes, so the buffering is not happening inside the server process.
The network. I can reproduce the same issue when running the server on the same machine as my web browser, and the amount of data that I am sending is far below the bandwidth constraints for a TCP connection to localhost.
This leaves the browser. Is there any way I can (a) determine the size of the buffer chrome is maintaining for my websocket, or (b) reduce the size of this buffer and cause chrome to drop frames?
(a) Chrome buffers around 128KB per WebSocket connection. The amount
of buffered data is not visible to the application.
(b) Chrome will never intentionally drop frames (this would violate the standard).
When the processing done by Javascript is trivial, Chrome can handle over 50 MB per second over a WebSocket. So it sounds like the processing you are doing is non-trivial. You can drop messages that are too old in the onmessage handler (but please bear in mind that the clock on the client may be out-of-sync with the clock on the server).
If the main thread of the browser is always busy, even dropping messages may not be enough to keep up. I recommend the "Performance" tab in Chrome Devtools as a good way to see where your application is spending its time.
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?.
Is there a way to alert a visitor that the website may load slowly because of their slow connetion?
i.e.
Heads up!
The page seems to be loading slowly becasue of your connection. Please allow extra time for the website to load.
You may download a known payload using ajax. Note down the request begin time and end time. If that is beyond some threshold you may alert the user about slow connection. For example, you download a 100 kb payload. You know under normal situations it takes 2 seconds. You may alert the user about slow network if it goes beyond acceptable threshold of say, 5 seconds. The payload you download need not be a waste request - you may use any ajax request for detecting the slow connections. This will work with one big assumption - your server is always responding quickly under heavy loads too - indicating only source of slow response is because of user's network conditions.
I'm trying to implement the service streaming pattern with Chrome's XMLHttpRequest object as a client in order to display an animation along a path determined by the server in real time. As noted at " Google Chrome and Streaming HTTP connections?" I've ensured a large chunk of data is sent on initial connection, and I am able to receive data from the server line by line. However, while the server is sending data periodically (every 300ms +- about 20ms) I'm getting an unacceptably large amount of jitter in chrome (up to +200ms for occasional lines). The server is running on localhost, so this is not network lag. Any ideas what might be causing it, or how I can fix it (short of buffering more of the animation than I currently am, which would be unacceptable as this is an interactive application)?