5 ms·

TIL about Falcon, which can power any rack app, including Rails: https://socketry.github.io/falcon/index.html https://socketry.github.io/falcon/index.html TIL

• alberth 5y ago
  Isn’t most of rails performing blocking operations. And as such, the numbers you stated above don’t hold true. The better graph to look at is the “Blocking Benchmark”, which shows all backends performing (equally) poorly.
  • sosodev 5y ago
    Async Ruby is rapidly maturing. I haven’t run Falcon in production yet but it’s not difficult at this point to setup Rails to take advantage of async IO.
    • cutler 5y ago
      I find these attempts to bolt async onto languages like Ruby and Python a bit pointless as the ecosystem isn't built around async so gems don't work. If your community rallies around async as the default and library output is growing then just maybe but it will take many years to catch-up. Python could maybe pull this off as library output is accelerating but for Ruby, where library output is declining (see https://modulecounts.com https://modulecounts.com), it seems futile.
      • ioquatix 5y ago
        The fiber scheduler solves this as concurrent execution is now built into the core of Ruby 3.
        • joelbluminator 5y ago
          Do you think it's perhaps confusing to call it async ruby? I was sure it works similar to node's async event loop but actually the fiber / fiber scheduler thing is more related to threads and doesn't use an event loop (?). It doesn't really matter I guess but the terminology "async" is kinda used in javascript land to mean event loop and afaik that's not what you're working on here right?
  • ninkendo 5y ago
    Indeed, the postgres drivers I’ve encountered are all blocking. On this topic, a warning for anyone trying to implement async rails with postgres: beware. Connections are per-thread in the ‘pg’ gem (and every other driver I’ve used), so one client’s connection may commit/abort another client’s transaction, and they end up stomping all over each other. Which you will only observe under load. There’s an eventmachine-based driver for postgres but it’s almost completely unmaintained afaict, and doesn’t work with any new rails versions. I spent a ton of effort migrating an internal rails app to eventmachine, only to realize at the very end that it fundamentally doesn’t work with typical CRUD/database apps. (Note, this experience was probably 4 or so years ago at this point, things may have matured since then, but I’d still say approach async rails with extreme caution.)
    • ioquatix 5y ago
      Non-blocking Postgres https://github.com/socketry/db-postgres https://github.com/socketry/db-postgres Non-blocking MariaDB https://github.com/socketry/db-mariadb https://github.com/socketry/db-mariadb
      • ioquatix 5y ago
        Also, it turns out the `pg` is also partially non-blocking. But AR may need to improve their connection pool implementation.
        • ninkendo 5y ago
          Does DB::Postgres work with ActiveRecord out of the box? The github page doesn’t mention anything about rails/AR. It also doesn’t seem like a super active project…
          • ioquatix 5y ago
            Nope, they are totally different. However, the DB gem is an interface/driver similar to PHP's PDO, while AR is a set of drivers, interfaces and high level ORM interfaces. In theory, one could probably use DB as a driver under AR. One person even basically uses AR to generate SQL and then executes it with the DB gem, which I thought was pretty clever.
• kayodelycaon 5y ago
  > Rails v5+ Rails v4+ :) Also, you need to use a thread-based app server like puma. App servers like unicorn do one process per request rather than threading.
  • rattray 5y ago
    Yes, falcon is a thread-based app server.
• joelbluminator 5y ago
  So what is the main advantage of this over say Puma/threads?
  • rattray 5y ago
    It claims better performance than puma.