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)?
Related
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!
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?.
Recently I have noticed that Chrome browser has Timing tab in the Network section.
This tab has the following elements:
Blocking
Sending
Waiting
Receiving
For example here is a screenshot for SO:
Also I think I know what sending, waiting and receiving means, I have no idea what Blocking means.
So what blocking means? What does it block and what makes these numbers smaller/bigger?
'Blocking' is the time difference between the HTTP request being ready to be sent and actually being sent. Formal definition here.
Why wasn't the request sent when it was ready to be sent? There could be multiple reasons for that, e.g.
The maximum number of TCP connections that the browser could open are all busy processing some other requests. E.g. Chrome opens upto 6 TCP connections per server/proxy. So this request has to wait till one of them gets free. Refer here for other browsers.
Proxy negotiation may be required for sending the request.
The machine running the browser may be slow or overloaded. So although the request is ready, it is busy doing something else.
I have a weird problem with websockets and chrome (22.0.1229.79m) (I haven't coded authentication for other browsers yet so I cant test them). It seems like if I reload chrome 3 times, there will be a huge delay in connecting to my websocket server. The server is not delaying the connection, I tested this by connecting to it with another PC while chrome was delaying and it connected perfectly.
Is there anyway to fix this? This is a problem when I am switching servers receiving data. It will halt, and delay. This is really bad for user experience. I would assume this is strictly related to the chrome browser not closing the socket...
I have also seen this delay when creating multiple WebSocket connections from the same browser tab in Chrome within a short period of time. I believe this is to address a potential security issue with WebSockets which would allow a browser to be hijacked to do port scanning inside a network. By limiting the number of WebSocket connections that can happen within a given amount of time, you greatly limit the utility of a browser as a remote port scanner. In addition, the amount of information that is returned by onclose and onerror is intentionally limited for the same reasons.