3 ms·

Can a normal web server (a Heroku dyno, for example) with a normal websocket library (https://github.com/gorilla/websocket https://github.com/gorilla/websocket,

by fiatjaf 10y ago

Can a normal web server (a Heroku dyno, for example) with a normal websocket library (https://github.com/gorilla/websocket 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?

jasonl99 10y ago
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.
JangoSteve 10y ago
It can. I have a demo deployed on Heroku for this app (https://github.com/JangoSteve/websockets-demo 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.
- jasonl99 10y ago
  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.
  - jasonl99 10y ago
    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.

3 ms·

Can a normal web server (a Heroku dyno, for example) with a normal websocket library (https://github.com/gorilla/websocket https://github.com/gorilla/websocket,

by fiatjaf 10y ago

jasonl99 10y ago
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.
JangoSteve 10y ago
It can. I have a demo deployed on Heroku for this app (https://github.com/JangoSteve/websockets-demo 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.
- jasonl99 10y ago
  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.
  - jasonl99 10y ago
    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.