Can a normal web server (a Heroku dyno, for example) with a normal websocket library (https://github.com/gorilla/websocket, for example) support multiple users connected at the same time?
How many in comparison to the number of normal web clients that do some XHR call from time to time?
It can. I have a demo deployed on Heroku for this app (https://github.com/JangoSteve/websockets-demo), and I've seen it handle maybe about 40 or 50 clients at a time on a single dyno before (and each client streaming a bunch of events), even though it's intentionally implemented in the simplest (i.e. inefficient) fashion possible. The request overhead for normal HTTP request/response goes away, since you only need the request headers and handshakes once at the beginning for a persistent connection.
I'm trying to get this demo working on an extremely inexpensive plain VPS (running Debian 7), and I'm getting "WebSocket connection to... failed: Invalid frame header". Is that what you saw when you as a result of hitting the 40-50 client limit? I am getting the error on a first connection, so it's probably something different.
I'm going to answer my own question - I tracked it down to a bug in lattice-core that occurred when it couldn't parse incoming JSON, and for some reason it killed the socket server. I fixed it by rescue the JSON parse and all is good now.
I haven't explored that a lot, but my thought was that the amount of setup/teardown for polling goes away, so it's at least an order of magnitude (guessing) better.
I have written the framework to use a single socket connection for all updateable objects on the page.
Comments
Can a normal web server (a Heroku dyno, for example) with a normal websocket library (https://github.com/gorilla/websocket, for example) support multiple users connected at the same time?
How many in comparison to the number of normal web clients that do some XHR call from time to time?
It can. I have a demo deployed on Heroku for this app (https://github.com/JangoSteve/websockets-demo), and I've seen it handle maybe about 40 or 50 clients at a time on a single dyno before (and each client streaming a bunch of events), even though it's intentionally implemented in the simplest (i.e. inefficient) fashion possible. The request overhead for normal HTTP request/response goes away, since you only need the request headers and handshakes once at the beginning for a persistent connection.
I'm trying to get this demo working on an extremely inexpensive plain VPS (running Debian 7), and I'm getting "WebSocket connection to... failed: Invalid frame header". Is that what you saw when you as a result of hitting the 40-50 client limit? I am getting the error on a first connection, so it's probably something different.
I'm going to answer my own question - I tracked it down to a bug in lattice-core that occurred when it couldn't parse incoming JSON, and for some reason it killed the socket server. I fixed it by rescue the JSON parse and all is good now.
I haven't explored that a lot, but my thought was that the amount of setup/teardown for polling goes away, so it's at least an order of magnitude (guessing) better.
I have written the framework to use a single socket connection for all updateable objects on the page.