Blocking behavior when using polling

[doenietzomoeilijk]

What I did:

• Set up a simple example server -- code and logs can be found in this gist
• Point a browser at it with a console open -- I'll see it sending kittens but not much else
• Open more browsers. For every new client I open, I'll get an extra puppy back for every kitten sent.

What I'd expect:

An unimpeded flow of pets, really. I feed it kittens, I get back puppies.

What actually happens:

• For 1 ~ 5 clients, everything is peachy. I'm getting 4 puppies for every 5 kittens, which is a pretty sweet deal.

• Beyond 5 active clients, however, things start blocking. In the browser, I see kittens being sent, but it takes about 20 seconds before I get any puppies back. I'll often get 101+ in one go.

  On the server side, I get the metrics every ten seconds, but not the usual debug output between two of those blocks.

• Bringing the number of clients back to 5 immediately speeds up the kitten and puppy transport.

  This can be observed in the node.log in the gist. There's also a v8.log that I ran through the tick-processor.

All things not being equal:

• If I don't force polling and use websockets, I get wonderful throughput (tried 26 clients).

• With FlashSocket, I get throughput although my browser somewhat dies from Too Much Flash (didn't dare to go beyond 7 clients).

• Using volatile or not doesn't seem to make one bit of difference: beyond 5 tabs, stuff starts lagging.

• Lowering 'polling duration' to 10 decreases the wait for puppies to, surprisingly, 10-ish seconds.

• Removing the forced polling and using 2 browsers, one that uses websockets and one that doesn't... hey, that's interesting.

  Using just the non-websockets browser exhibits the usual behaviour (problems beyond 5 tabs), but opening up 1 tab in the websockets-capable browser, the puppies suddenly start flowing again. It might be somewhat irregular -- at 1 websocket and 10 non-websocket tabs, I might see 10 puppies most of the times, sometimes a couple more, sometimes a couple less -- but most of the time it's allright, and at least the puppies keep coming.

Environment:

Node.js 0.4.9, Socket.io freshly pulled from the master repo, running on a Linux box. CPU load is not, at any point, a problem. Browsers were Chrome and Firefox 3, on a different machine in the local network.

Conclusion:

It seems to me it's an issue with the polling mechanism. Strangely enough it goes away if there's a websockets connection tagging along.

[doenietzomoeilijk]

A little clarification after some more testing: the blocking behaviour is only seen if there's more than 5 tabs open in all clients. If I force xhr-polling and pull up 6 tabs in firefox, it blocks. Open one tab in Chrome and it's running again. Open 5 more in Chrome and it's blocking again. Open one tab in Safari and we're back in smooth pet business.

I've tried sprinkling console.logs in various places, but it doesn't seem to handle anything while blocked. Stuff that runs through setInterval() does, however work (the metrics in server.js, garbage collection, that kind of thing).

Edit: went into Firefox' about:config, changed network.http.max-persistent-connections-per-server from 6 to 20, and lo and behold: I can suddenly open a lot more tabs, while keeping constant updates. I suppose we can close this problem then, but it might be worth it to mention this behaviour in the docs somewhere. At the least it might save some poor sap from having to search for a solution that isn't there. =]
This does make the blocking somewhat less of a problem (assuming people will only have one tab per client open, which might not always be the case), but the more I look at it, the less I understand about the problem (or rather, the more I start to think this might actually be a browser limit).

Edit 2: With the max persistant connections set to 20, I can, surprisingly enough, open only 14 tabs before it's blocking time again. Not sure where this originates.

[3rd-Eden]

Are you forcing xhr-polling in safari and chrome? As https://gist.github.com/1261741#file_server.js doesn't do a
io.set('transports', .. )

@doenietzomoeilijk what happens if you distribute the connection over multiple hostnames because you might be hitting the build in browserlimit of max amount of connections per hostname.

[doenietzomoeilijk]

The xhr-poll-forcification is done by sourcing /socket.io/socket.io+xhr-polling.js, which is a trick you taught me. =]

Might try the different hostnames thing, but I'm inclined to say that it will work. A quick check later Yes, it does indeed work. Even with the standard value (6) for network.http.max-persistent-connections-per-server I can open 14 or more tabs on one hostname, provided I have at least one tab open on a different hostname (that, to clarify, points to the same server). So, technically, I don't seem to hit that actual limit as such. I wonder where it does come from.

Does Node itself have any limitations? I'll do a google on that.