4 ms·

I wonder how many WebSocket connections one dyno can take? Also seems like this would make heroku's routing problems[1] even worse. [1] http://news.rapgenius.

by sync 13y ago

I wonder how many WebSocket connections one dyno can take? Also seems like this would make heroku's routing problems[1] even worse. [1] http://news.rapgenius.com/Jesper-joergensen-routing-performance-update-lyrics http://news.rapgenius.com/Jesper-joergensen-routing-performa... et al.

deleted 13y ago
[deleted]
bgentry 13y ago
> Also seems like this would make heroku's routing problems[1] even worse. No, this will not make routing issues worse. The routing issues described in that post specifically apply to single-threaded / non-concurrent applications (or those with very low concurrency, such as Unicorn w/ 2 workers). WebSocket connections are like requests that last forever. If you're using WebSockets in your app, you'll need your app to be highly concurrent in order to maintain lots of open connections to your users. You don't want regular requests to block behind never-ending WebSocket requests. Random routing should actually work pretty well on apps with high concurrency. Node.js, Play, Go, Erlang, and even Ruby apps with Faye should all work great. If you're concerned about this for your app, the best way to find out is to test it!
- timr 13y ago
  That's a little disingenuous. You've selected a very specific set of frameworks, whereas most of the users here are probably thinking "great! I can run my Rails stack with no problems! Heroku engineer said so!" Note to readers: the only thing that "fixes" this is if the request-handling code is asynchronous in such a way that it doesn't block a process when connections are held idle. Most of the common web frameworks don't do this because the coding required to make a fully asynchronous stack is nasty. Even apps written in nominally asynchronous frameworks (like node.js) could be in trouble if the request path is pathological (i.e. the websocket periodically makes long-running, blocking database queries). That said, most of you will never encounter this problem, because it's the sort of problem that's "nice to have" -- by the time concurrency issues become a limit, your app will be popular.
  - ikawe 13y ago
    I don't think that's disingenuous. It's safe to assume that anyone who hopes to leverage websockets will not be using a blocking application architecture. We can also assume people are running this software on multiprocessing machines with connections to the internet. Of course there's always people "doing it wrong," but caveating every potential misunderstanding is a slow way to communicate. edit: Your post is still valuable though! Thanks for highlighting what makes these frameworks sensible for use with websockets.
    - timr 13y ago
      "It's safe to assume that anyone who hopes to leverage websockets will not be using a blocking application architecture." No, it isn't. I'll wager that right this very second, there's someone out there incorporating websockets into their Heroku-based Rails app and not thinking about (or understanding) the consequences.
      - wmf 13y ago
        Wouldn't such an app be hosed on almost any platform due to massive memory waste?
        gnur 13y ago
        I don't think the memory waste is the problem in this case, a websocket is a long lived connection. If you mix it with regular requests and don't think about the concurrency consequences you'll be able to serve 1 request and then allow for 1 websocket connection and your done. All other connections will be pending until the websocket is closed.
  - tlrobinson 13y ago
    bgentry's comment didn't seem disingenuous to me at all, and I was surprised by sync's question. WebSocket connections are long lived, thus if your framework only supports one (or a few) concurrent connection you're gonna have a bad time. Heroku's past routing problems with certain low concurrency frameworks/servers doesn't apply with WebSockets because you'd be crazy to use such a framework for WebSockets.

by sync 13y ago

deleted 13y ago

[deleted]

bgentry 13y ago

> Also seems like this would make heroku's routing problems[1] even worse. No, this will not make routing issues worse. The routing issues described in that post specifically apply to single-threaded / non-concurrent applications (or those with very low concurrency, such as Unicorn w/ 2 workers). WebSocket connections are like requests that last forever. If you're using WebSockets in your app, you'll need your app to be highly concurrent in order to maintain lots of open connections to your users. You don't want regular requests to block behind never-ending WebSocket requests. Random routing should actually work pretty well on apps with high concurrency. Node.js, Play, Go, Erlang, and even Ruby apps with Faye should all work great. If you're concerned about this for your app, the best way to find out is to test it!

timr 13y ago
That's a little disingenuous. You've selected a very specific set of frameworks, whereas most of the users here are probably thinking "great! I can run my Rails stack with no problems! Heroku engineer said so!" Note to readers: the only thing that "fixes" this is if the request-handling code is asynchronous in such a way that it doesn't block a process when connections are held idle. Most of the common web frameworks don't do this because the coding required to make a fully asynchronous stack is nasty. Even apps written in nominally asynchronous frameworks (like node.js) could be in trouble if the request path is pathological (i.e. the websocket periodically makes long-running, blocking database queries). That said, most of you will never encounter this problem, because it's the sort of problem that's "nice to have" -- by the time concurrency issues become a limit, your app will be popular.
- ikawe 13y ago
  I don't think that's disingenuous. It's safe to assume that anyone who hopes to leverage websockets will not be using a blocking application architecture. We can also assume people are running this software on multiprocessing machines with connections to the internet. Of course there's always people "doing it wrong," but caveating every potential misunderstanding is a slow way to communicate. edit: Your post is still valuable though! Thanks for highlighting what makes these frameworks sensible for use with websockets.
  - timr 13y ago
    "It's safe to assume that anyone who hopes to leverage websockets will not be using a blocking application architecture." No, it isn't. I'll wager that right this very second, there's someone out there incorporating websockets into their Heroku-based Rails app and not thinking about (or understanding) the consequences.
    - wmf 13y ago
      Wouldn't such an app be hosed on almost any platform due to massive memory waste?
      - gnur 13y ago
        I don't think the memory waste is the problem in this case, a websocket is a long lived connection. If you mix it with regular requests and don't think about the concurrency consequences you'll be able to serve 1 request and then allow for 1 websocket connection and your done. All other connections will be pending until the websocket is closed.
- tlrobinson 13y ago
  bgentry's comment didn't seem disingenuous to me at all, and I was surprised by sync's question. WebSocket connections are long lived, thus if your framework only supports one (or a few) concurrent connection you're gonna have a bad time. Heroku's past routing problems with certain low concurrency frameworks/servers doesn't apply with WebSockets because you'd be crazy to use such a framework for WebSockets.