4 ms·

i think this announcement https://brunosutic.com/blog/async-ruby https://brunosutic.com/blog/async-ruby & the associated async libraries (https://github.com/soc

i think this announcement https://brunosutic.com/blog/async-ruby https://brunosutic.com/blog/async-ruby & the associated async libraries (https://github.com/socketry/async https://github.com/socketry/async) do a much better job of showing off the potential for the ruby 3.1+ fiber scheduler. Async gem is powered by a fiber scheduler under the hood, and what you get is un-colored async-ready ruby code. That is to say, you can write a normal rack app with falcon-async as the webserver and get node/event-loop scale co-operative concurrency without changing your code. Its pretty exciting! Unfortunately rails makes heavy use of thread locals which arent compatible with fiber concurrency, so its going to take awhile until its async-ready, but I believe progress is being made (Async ActiveRecord was merged recently).

byroot 4y ago
Active Record async queries have nothing to do with fibers, the fiber scheduler or the `async` library. As for the heavy use of thread locals, we introduced an indirection to solve the problem. I can't say for sure every thing is ironed out, but if people find other issues we'll fix them. That said, don't expect any performance gain running a typical Rails app with falcon. Like NodeJS, It only makes sense if your app is predominantly IO.
- endorphine 4y ago
  Isn't the typical Rails app IO-bound?
  - byroot 4y ago
    It very much isn't. Most well crafted Rails apps try to minimize IOs inside web requests by deferring any long IO into background job, and trying to optimize SQL queries. At best you may find apps that are 50% IOs. That may seems like a lot, but since you can only execute one fiber (or thread) at a time (because there is a GVL), that means two concurrent requests per process. So in such scenario there isn't a lot of benefit in making fibers your main execution primitive (each request get one fiber). You'll save a handful of MB of RAM, but loose thread preemption, meaning your latency will frequently be impacted. Doesn't mean fibers are useless though. You can still have a mix of forking and threads, and then use fibers inside your request cycle to query resources concurrently. But fiber based servers are not really well suited for hosting Rails apps. They're much more suited for extremely IO heavy tasks, like proxies or bridge. e.g you subscribe to Redis and forward events into a websocket, that sort of things.
    - endorphine 4y ago
      > At best you may find apps that are 50% IOs. What is the rest 50% typically?
      - byroot 4y ago
        CPU tasks (rendering views, instantiating objects, crunching numbers, etc) and GC.
- dalyons 4y ago
  sorry i should have been crisper in my language - there is the new AR async queries (which as you correctly said is a totally different thing). And then there is separately fibered support in activerecord, which will allow the use of the async library for co-op concurrency. Yeah I dont expect single path performance gain, what i'm hopeful for is more concurrency for the same memory across a large pool of web workers in a high scale app. Thus saving a bunch of $$$ EDIT: i just saw your other comment, i suppose you're right w.r.t latencies, there may be less benefit to this than i expected for a standard rails app.

byroot 4y ago

Active Record async queries have nothing to do with fibers, the fiber scheduler or the `async` library. As for the heavy use of thread locals, we introduced an indirection to solve the problem. I can't say for sure every thing is ironed out, but if people find other issues we'll fix them. That said, don't expect any performance gain running a typical Rails app with falcon. Like NodeJS, It only makes sense if your app is predominantly IO.

endorphine 4y ago
Isn't the typical Rails app IO-bound?
- byroot 4y ago
  It very much isn't. Most well crafted Rails apps try to minimize IOs inside web requests by deferring any long IO into background job, and trying to optimize SQL queries. At best you may find apps that are 50% IOs. That may seems like a lot, but since you can only execute one fiber (or thread) at a time (because there is a GVL), that means two concurrent requests per process. So in such scenario there isn't a lot of benefit in making fibers your main execution primitive (each request get one fiber). You'll save a handful of MB of RAM, but loose thread preemption, meaning your latency will frequently be impacted. Doesn't mean fibers are useless though. You can still have a mix of forking and threads, and then use fibers inside your request cycle to query resources concurrently. But fiber based servers are not really well suited for hosting Rails apps. They're much more suited for extremely IO heavy tasks, like proxies or bridge. e.g you subscribe to Redis and forward events into a websocket, that sort of things.
  - endorphine 4y ago
    > At best you may find apps that are 50% IOs. What is the rest 50% typically?
    - byroot 4y ago
      CPU tasks (rendering views, instantiating objects, crunching numbers, etc) and GC.
dalyons 4y ago
sorry i should have been crisper in my language - there is the new AR async queries (which as you correctly said is a totally different thing). And then there is separately fibered support in activerecord, which will allow the use of the async library for co-op concurrency. Yeah I dont expect single path performance gain, what i'm hopeful for is more concurrency for the same memory across a large pool of web workers in a high scale app. Thus saving a bunch of $$$ EDIT: i just saw your other comment, i suppose you're right w.r.t latencies, there may be less benefit to this than i expected for a standard rails app.