Heroku WebSockets Now in Public Beta
blog.heroku.com
blog.heroku.com
Also seems like this would make heroku's routing problems[1] even worse.
[1] http://news.rapgenius.com/Jesper-joergensen-routing-performa... et al.
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!
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.
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.
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.
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.
Rails only supports one concurrent connection per process (by default...for good reasons), and there are a great many people using it at scale, including on Heroku. Asynchronous stacks are becoming more common, but they're still exotic in terms of deployment -- and most of those probably aren't written very well.
And I think lots of people would disagree that async stacks are still "exotic" or "not written very well".
Yes, no kidding. But people will still try to do this with frameworks that don't support anything else (like Rails), because that's the shortest path to a working product.
"And I think lots of people would disagree that async stacks are still "exotic" or "not written very well"."
Well, those "lots of people" can disagree all they want, but they're wrong. The problem isn't that the frameworks are badly written, necessarily -- it's all the stuff in the stack, including the app-specific logic. Virtually no one knows how to write asynchronous web apps of any complexity. It's a very hard problem.
It's nice that you guys are adding this stuff, but it doesn't invalidate the larger point.
As the WebSocket standard is very recent, it has never been supported by ELBs in HTTP mode.
ELBs in TCP mode can support any TCP traffic. It's become clear that we need this flexibility, so we're moving to TCP-mode ELBs now. This was not trivial, though, as long-lived connections (like those used for WebSockets) have different implications for our HTTP routers. That had to be taken account.
Nonetheless, we've had a private beta for a long time that worked as described above. But we deemed it insufficient for general customer use because TCP-mode ELBs mean that you lose the client's source IP and protocol. Fortunately, ELBs now have Proxy Protocol support [2], which allows us to keep that request information that Heroku apps typically rely on.
[1] More info on ELB modes: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/Devel...
[2] http://aws.typepad.com/aws/2013/07/elastic-load-balancing-ad...
WebSocket has been around since 2010. This is just confirmation to me that Heroku isn't a good fit for apps targeting new web technologies. It's a good fit for apps targeting IE8.
http://aws.typepad.com/aws/2013/07/elastic-load-balancing-ad...
EDIT: also when 2 years ago I did load testing with ELB and created 1 million concurrent WebSocket connections, I did received mail from Amazon asking what the hell I doing and was asked to stop it ;)
You'll need to send some data every ~55s or so in order to keep the connection alive.
http://evening-meadow-5281.herokuapp.com/
It's pretty shoddy, but this might give me some inspiration to move forward.
The nice thing about socket.io, is it prefers websockets, but will fall back to long polling if not available on both the client and server.
So this didn't even require a redeploy, just a `heroku labs:enable websockets`
And like magic I can support more than 10 concurrent users ;)
The biggest problem I've had with Socket.io on PaaS's is it pretty much expects every request from a particular client to be routed to the same backend (i.e. sticky sessions), which works ok with a single backend but obviously doesn't scale.
Given Heroku's stateless routing architecture, I'd guess no, but maybe there's something I'm missing?
"A potentially big drawback with this is that socket.io sessions are not shared between workers. This will probably mean problems if you use any of the long-polling transports."
Hopefully I'll be proven wrong.
From my benchmarks, there is a measurable difference between cloud VPS WebSocket latency/bandwidth and dedicated server WebSocket latency/bandwidth.
If you Heroku guys are still listening... I'm so fucking impressed that you already updated the docs I was using earlier. I was going to suggest you update them... but then I went to grab the link and it was updated. Well done.
This is probably in reference to Amazon forbidding the use of another software load balancer than ELB.
I also read on reddit that there is in fact just ELB. Especially when if you require a loadbalancer and don't host on AWS, you're pretty much screwed.
[Note, sarcasm.]