I'd welcome refactorings to tease out the socket dynamics from the higher level bits. So do submit a PR on that. I've replied on the other PR re: callbacks. Thanks for working on this!
On Wednesday, December 28, 2016 at 9:29:35 AM UTC-8, [email protected] wrote: > > Hey, everyone! > > 1. Action Cable *built-in *server is a great feature: "out-of-the-box" == > "developer happiness". That's why we use Rails, don't we? > That's why I'm trying (as the author of AnyCable) to develop a transparent > replacement for Action Cable server, only for production use, especially > high-load. > > So, I don't think we should extract the Action Cable server from the > framework. > > But, as for me, we should think about decoupling application logic from > low-level logic. There are some places in the codebase, where we mix > application level logic with *socket level *logic – the Connection > <https://github.com/rails/rails/blob/v5.0.1/actioncable/lib/action_cable/connection/base.rb> > > class, for example. It would be great to extract its *public API* (that > we use in ApplicationCable::Connection). > > Another example is the explicit usage of the server's event loop > <https://github.com/rails/rails/blob/v5.0.1/actioncable/lib/action_cable/channel/streams.rb#L85> > > in channels. > > That's why I have to patch these classes in AnyCable. But it would be > better to avoid monkey-patching in favor of adapter-like implementation. > > Btw, I've received a lot of requests to support AnyCable for non-Rails > applications (yep, sounds a little bit strange) and I'm going to implement > smth like *Action Cable Lite* – no Rails, no server, just application > logic (channels, streams). Maybe, that could be a starting point to > refactor the Action Cable. > > 2. I've repeated WebSocket Shootout for many times, but I haven't seen > Action Cable crashing. It eats a lot of memory; it can be slow for > broadcasting (when more than 1k connections per stream). > But it works. > > > On Monday, December 26, 2016 at 11:07:02 PM UTC+3, DHH wrote: >> >> 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. >> > > Btw, there is an issue (https://github.com/rails/rails/issues/26999) with > some proposals. > > The most *problematic* feature (from the AnyCable point of view or other > *adapters, > *if any) – custom streaming callbacks. I'd like them to be deprecated) > Why? First, because they affect performance: straightforward broadcasting > is much more efficient (=faster). And, secondly, IMO, it breaks the concept > of broadcasting itself – we're not simply re-transmitting messages to all > clients, but we can do anything in the middle, different clients may > receive different messages – should we have used different streams instead? > > Do you use custom callbacks in Basecamp? > > > >> >> 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, [email protected] 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
