4 ms·
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
by 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 agoIsn't the typical Rails app IO-bound?
- byroot 4y agoIt 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 agoCPU tasks (rendering views, instantiating objects, crunching numbers, etc) and GC.
- dalyons 4y agosorry 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.