Hey, AnyCable looks lovely and it'll be interesting to follow the new Rack specification. But Action Cable should work out-of-the-box with no additional servers or setups required beyond Puma. If there are options available that fulfill that criteria and are drop-in replacements, awesome, let's look at that. Also happy to accommodate whatever AnyCable might need, but haven't seen any requests.
So let's wait to see some real approaches that need the existing server extracted before we venture down that path. Whatever benchmarks that were done against 5.0.0 should take another go against 5.0.1. Tons of Action Cable fixes for both performance and stability. But regardless of what that changes, the overall story will remain the same. Ruby is never going to win any Hello World shoot-out against C++ or microframeworks. That's as true for a regular 200 OK request as it is for a websockets connection. That doesn't mean we shouldn't seek to improve performance, and options like AnyCable might do so dramatically, just that we should have realistic expectations of where things go. For Basecamp 3, which Action Cable was developed for and extracted from, our main issue has been less raw websocket performance and more just doing the work that is needed across that wire. Kinda like how doing 2,000 req/sec on a "Hello World" 200 OK is a bit irrelevant compared to building a real app. It's extremely unlikely that the overhead of your underlying server is going to be the bottleneck. It's more likely to be your application logic. All depends on your use case, of course. And happy to see others push the performance of Action Cable further. As-is, it's plenty good enough to run a major app like Basecamp 3. On Friday, December 23, 2016 at 10:35:06 PM UTC-8, b...@bowild.com wrote: > > This issue is a discussion, not a bug report. > > I'm opening the question for discussion because: > > 1. With [AnyCable](http://anycable.evilmartians.io) in mind and in with > the new [Websocket Rack specification proposal]( > https://github.com/boazsegev/iodine/blob/master/SPEC-Websocket-Draft.md), > separation of concerns might be beneficial (similar to the way the web > server was extracted). > > 2. The [Websocket-Shootout benchmark]( > https://hashrocket.com/blog/posts/websocket-shootout) had some very > troubling results. I emailed Jack about it and he pointed out that > ActionCable was crashing as well as slow. > > I believe that similar to the way the HTTP server was extracted from > earlier Rails versions, the extraction of the Websocket server (the event > loop currently based on `nio4r`) with a clear API, could both make > maintenance easier and allow for performance improvements (i.e., by > utilizing a platform specific optimized server). > > What is your opinion? > > Should the ActionCable server be extracted from ActionCable? > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
