6 ms·

This seems huge. Does anyone know plans around how this will be implemented into Rails?

hiyer 5y ago
From reading the article it seems to me that you could just wrap any Rails method (say a DB read) in an Async block to make it run asynchronously.
- rajangdavis 5y ago
  Also says at the end: The only caveat is that it doesn't work with Ruby on Rails, because ActiveRecord doesn't support async gem. You can still use it with Rails if ActiveRecord is not involved.
  - hiyer 5y ago
    Oh, sorry I missed that. Hopefully it will show up in Rails 7 then.
    - rajangdavis 5y ago
      You're not wrong. If you have external services that are accessible via HTTP, there is some potential to get some performance gains there. You're just limited in terms of some of the core Rails utilities.
  - DangitBobby 5y ago
    I don't understand. Is this misleading then? Did HTTParty have to implement Async for their example to work? > You probably have your preferred HTTP gem, and you may be asking "will it work with Async"? To find out, here's an example using HTTParty, a well-known HTTP client. They then go to show that your "preferred HTTP gem" will just work. How is the ActiveRecord situation different?
    - ioquatix 5y ago
      ActiveRecord does work but it’s hugely limited because they have explicit per-thread resource pools which we can’t get around very easily.
      - DangitBobby 5y ago
        Okay, that makes sense.
      - joelbluminator 5y ago
        I'm guessing this problem also applies to Action Cable?
rajangdavis 5y ago
I think there has to be massive benefit to the Rails community before there can be a consideration of adding such a feature. I could be wrong here, but I'm not sure it will solve some of the more drastic issues of what happens in a production Rails app which I believe to be mostly around memory and garbage collection (from my limited experience and understanding). You might be able to eke out more performance in terms of having more clients be able to hit a page, but I suspect that might make memory more of an issue, not less.
- joelbluminator 5y ago
  How about ActionCable though? That's a big one I'm wondering about with Fibers/Async
  - rajangdavis 5y ago
    No clue... I could be wrong, but the underlying technology for ActionCable is Web Sockets and I'm not sure what problems async would solve there.
    - joelbluminator 5y ago
      I'm guessing the Rails implementation for the webs sockets part is thread-based and if that's the case fibers can make a big difference. But I'm also a bit out of my depth here.
    - kovacs 5y ago
      I think what's being talked about here is the back end implementation for ActionCable. By default it uses ruby threads to push over open web sockets. There's at least one production quality drop in implementation (https://anycable.io/ https://anycable.io/) that address the default scalability issues you'll have with ActionCable. The async support would seem to allow one to go much further with default rails before needing to move to something more performant.
    - jrochkind1 5y ago
      The problem it would solve is a back-end process handling multiple Web Sockets connections, efficiently.
brunosutic 5y ago
Yea, it's a big new Ruby feature. From what I was able to tell (I followed the discussion around this) enabling Rails to work with Async is not huge amount of effort. One guy was working on this, but he got distracted with other stuff. It's just a matter of time someone steps up and gets this to work.
- jrochkind1 5y ago
  I am not sure this is so. https://news.ycombinator.com/item?id=29050482 https://news.ycombinator.com/item?id=29050482
Mikeb85 5y ago
It's not particularly huge, it's just another gem. Rails already does things concurrently and in parallel. https://guides.rubyonrails.org/threading_and_code_execution.html https://guides.rubyonrails.org/threading_and_code_execution....
- joelbluminator 5y ago
  It does it with threads though, which has implication when we talk about moderate/big traffic and Action Cable. A big win would be if Action Cable will be able to work with Fibers/Async or something equivalent. It's an annoying performance bottleneck and it would be super awesome if Ruby/Rails just solves it.
adverbly 5y ago
This is all new to me as well, but the project mentioned the Falcon web server(https://github.com/socketry/falcon https://github.com/socketry/falcon). The documentation for Falcon mentions using it with rails: https://socketry.github.io/falcon/guides/rails-integration/index.html https://socketry.github.io/falcon/guides/rails-integration/i... I imagine something more "native" to rails will happen eventually though. But would need to be after this makes its way into core ruby(which has not happened yet apparently).

From reading the article it seems to me that you could just wrap any Rails method (say a DB read) in an Async block to make it run asynchronously.

rajangdavis 5y ago
Also says at the end: The only caveat is that it doesn't work with Ruby on Rails, because ActiveRecord doesn't support async gem. You can still use it with Rails if ActiveRecord is not involved.
- hiyer 5y ago
  Oh, sorry I missed that. Hopefully it will show up in Rails 7 then.
  - rajangdavis 5y ago
    You're not wrong. If you have external services that are accessible via HTTP, there is some potential to get some performance gains there. You're just limited in terms of some of the core Rails utilities.
- DangitBobby 5y ago
  I don't understand. Is this misleading then? Did HTTParty have to implement Async for their example to work? > You probably have your preferred HTTP gem, and you may be asking "will it work with Async"? To find out, here's an example using HTTParty, a well-known HTTP client. They then go to show that your "preferred HTTP gem" will just work. How is the ActiveRecord situation different?
  - ioquatix 5y ago
    ActiveRecord does work but it’s hugely limited because they have explicit per-thread resource pools which we can’t get around very easily.
    - DangitBobby 5y ago
      Okay, that makes sense.
    - joelbluminator 5y ago
      I'm guessing this problem also applies to Action Cable?

rajangdavis 5y ago

I think there has to be massive benefit to the Rails community before there can be a consideration of adding such a feature. I could be wrong here, but I'm not sure it will solve some of the more drastic issues of what happens in a production Rails app which I believe to be mostly around memory and garbage collection (from my limited experience and understanding). You might be able to eke out more performance in terms of having more clients be able to hit a page, but I suspect that might make memory more of an issue, not less.

joelbluminator 5y ago
How about ActionCable though? That's a big one I'm wondering about with Fibers/Async
- rajangdavis 5y ago
  No clue... I could be wrong, but the underlying technology for ActionCable is Web Sockets and I'm not sure what problems async would solve there.
  - joelbluminator 5y ago
    I'm guessing the Rails implementation for the webs sockets part is thread-based and if that's the case fibers can make a big difference. But I'm also a bit out of my depth here.
  - kovacs 5y ago
    I think what's being talked about here is the back end implementation for ActionCable. By default it uses ruby threads to push over open web sockets. There's at least one production quality drop in implementation (https://anycable.io/ https://anycable.io/) that address the default scalability issues you'll have with ActionCable. The async support would seem to allow one to go much further with default rails before needing to move to something more performant.
  - jrochkind1 5y ago
    The problem it would solve is a back-end process handling multiple Web Sockets connections, efficiently.

brunosutic 5y ago

Yea, it's a big new Ruby feature. From what I was able to tell (I followed the discussion around this) enabling Rails to work with Async is not huge amount of effort. One guy was working on this, but he got distracted with other stuff. It's just a matter of time someone steps up and gets this to work.

jrochkind1 5y ago
I am not sure this is so. https://news.ycombinator.com/item?id=29050482 https://news.ycombinator.com/item?id=29050482

Mikeb85 5y ago

It's not particularly huge, it's just another gem. Rails already does things concurrently and in parallel. https://guides.rubyonrails.org/threading_and_code_execution.html https://guides.rubyonrails.org/threading_and_code_execution....

joelbluminator 5y ago
It does it with threads though, which has implication when we talk about moderate/big traffic and Action Cable. A big win would be if Action Cable will be able to work with Fibers/Async or something equivalent. It's an annoying performance bottleneck and it would be super awesome if Ruby/Rails just solves it.

adverbly 5y ago

This is all new to me as well, but the project mentioned the Falcon web server(https://github.com/socketry/falcon https://github.com/socketry/falcon). The documentation for Falcon mentions using it with rails: https://socketry.github.io/falcon/guides/rails-integration/index.html https://socketry.github.io/falcon/guides/rails-integration/i... I imagine something more "native" to rails will happen eventually though. But would need to be after this makes its way into core ruby(which has not happened yet apparently).