Menu
I'm planning on writing a Rails app where multiple users are going to have updated information pushed to them using server-sent events with ActionController::Live and Puma. I've already written a test app and it seems to work very well. For what I'm doing, SSEs make more sense than WebSockets as most of the users are just 'listening' and SSEs are much simpler than setting up websockets-rails which also depends on Faye(in which case I'd just write my own code on top of Faye).
What I want to know is just how scalable are server-sent events in Rails? This is under the premise that I'll be using Puma, which creates a new thread for every user who is connected to the EventSource. Potentially, this app aims towards the possibility of having hundreds of thousands of users connected at once, but by Puma's default thread limit is 16. Is there any reason why I can't change the thread limit to 200,000?
969
SSE is best used when it's not necessary to send data from client to server. For example, in status updates and push notification applications, the data flow is from the server to the client only. This is what SSE is designed for, so WebSocket would be overkill. It's always wise to use the best tool for the job.
Server Sent Events are still not production ready after a decade.
Server-Sent Events (SSE) is a server push technology enabling a client to receive automatic updates from a server via an HTTP connection, and describes how servers can initiate data transmission towards clients once an initial client connection has been established.
Simply put, Server-Sent-Events, or SSE for short, is an HTTP standard that allows a web application to handle a unidirectional event stream and receive updates whenever server emits data. Spring 4.2 version already supported it, but starting with Spring 5, we now have a more idiomatic and convenient way to handle it.
If Puma creates a new thread for each connection, don't use it. Not only do you plan for hundreds of thousands users at once but provided it's going to be a web application, users can have multiple instances open in multiple browser tabs. Even the SSE specification warns against the "multiple tabs" problem because browsers may have their own limits of the number of simultaneous connections to one host:
Clients that support HTTP's per-server connection limitation might run into trouble when opening multiple pages from a site if each page has an EventSource to the same domain. Authors can avoid this using the relatively complex mechanism of using unique domain names per connection, or by allowing the user to enable or disable the EventSource functionality on a per-page basis, or by sharing a single EventSource object using a shared worker.
Use an evented server where connections do not block. The above-mentioned gevent, something built on Node JS or something else in Ruby (which I don't know and thus can't recommend anything).
For other readers who land on this page and might get confused, Rich Peck's answer is wrong. Server-Sent Events don't rely on long polling, nor do they send requests every couple of seconds. They are long-lived HTTP connections without the need to reopen the connection after every event. There are no "constant requests to the server".
131
About the Puma approach using one thread per client, given you have a limit of 16 threads per server, maybe you can think about horizontal scaling your servers? Like, if you deploy to amazon and set up Elastic Load Balancing + Auto Scaler, your infrastructure shoud be able to accept as many clients as needed. Or am I wrong ? And I guess the multiple tabs problem could be overpassed by forbidding multiple connections per client, displaying an appropriate error message if the user opens a new tab.
26
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
