3 ms·

That is precisely my point. One has concurrency capped at 5, the other has no cap (because it uses an event loop). The Puma process is likely 99% idle in that

by byroot 3y ago

That is precisely my point. One has concurrency capped at 5, the other has no cap (because it uses an event loop). The Puma process is likely 99% idle in that benchmark, you could crank up the thread count to 50 and get (not quite) 10x better results. An event loop is definitely more efficient than a thread pool for such a work-load, I'm not denying that, but in this specific instance Rails+Puma is configured (granted it's just the defaults) with ball and chain. I'm not saying the benchmark is dishonest, I'm saying it makes no sense.

ricardobeat 3y ago
That objection makes no sense. The fact that Puma is idle most of the time reflects a disadvantage. The event loop makes much better usage of a single thread, and that shows in the benchmark. It's like saying comparing Node to Rhino, or Vertx vs Spring Boot is unfair. Better performance per thread / core is the whole point. You will not achieve the same level of performance with threads except in low-volume benchmarks, and _especially_ in any kind of cloud environment where you usually only have a single core and a shared kernel.
- byroot 3y ago
  My point is that event loop are not inherently superior to thread pools. When you have a workload that is CPU heavy enough that you won't have more than a handful of threads of concurrency, using a thread pool will allow preemption, hence give you a better tail latency, etc. It's all tradeoff, event loops are good for some work loads, threads for others. So to make an analogy of my own, it's like making a race between an F1 car and a semi-truck. They are both useful and efficient motor vehicule, but they're not optimized for the same thing.
  - ricardobeat 3y ago
    That's true. Would you then agree that an event loop is very well suited for web server workloads, with short lived requests + reasonably light CPU usage + lots of IO, which happens to be the territory both Rage and Puma are situated? You said the benchmark is "entirely irrelevant" because it doesn't take into account a scenario that is explicitly not the goal of either project. For those workloads Ruby is already far down the list of best choices.
    - byroot 3y ago
      > Would you then agree that an event loop is very well suited for web server workloads, with short lived requests + reasonably light CPU usage + lots of IO, which happens to be the territory both Rage and Puma are situated? No, that's where I disagree. The average Ruby web application isn't as IO heavy as people claim, and often contains big chunks of CPU work (typically HTML templating or JSON generation/parsing) that run havoc in an event loop. My measurements on dozens of Rails app showed the IO ratio tend to be in the 30-70% range. Most closer to 50%. The apps that do more IO than that either have terribly optimized DB queries, or are mostly acting as some sort of HTTP client for an API, but from my experience that's the exception, not the rule. > For those workloads Ruby is already far down the list of best choices. Raw speed is far from the only criteria when one chose a stack...
      - thaosdfjw 3y ago
        That's interesting. Does that mean the typical Ruby workload would be a better match for userspace preemptive threads like BEAM?
        dang 3y ago
        Could you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comment&storyText=false&prefix&page=0&query=community%20identity%20by:dang https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...

by byroot 3y ago

ricardobeat 3y ago

That objection makes no sense. The fact that Puma is idle most of the time reflects a disadvantage. The event loop makes much better usage of a single thread, and that shows in the benchmark. It's like saying comparing Node to Rhino, or Vertx vs Spring Boot is unfair. Better performance per thread / core is the whole point. You will not achieve the same level of performance with threads except in low-volume benchmarks, and _especially_ in any kind of cloud environment where you usually only have a single core and a shared kernel.

byroot 3y ago
My point is that event loop are not inherently superior to thread pools. When you have a workload that is CPU heavy enough that you won't have more than a handful of threads of concurrency, using a thread pool will allow preemption, hence give you a better tail latency, etc. It's all tradeoff, event loops are good for some work loads, threads for others. So to make an analogy of my own, it's like making a race between an F1 car and a semi-truck. They are both useful and efficient motor vehicule, but they're not optimized for the same thing.
- ricardobeat 3y ago
  That's true. Would you then agree that an event loop is very well suited for web server workloads, with short lived requests + reasonably light CPU usage + lots of IO, which happens to be the territory both Rage and Puma are situated? You said the benchmark is "entirely irrelevant" because it doesn't take into account a scenario that is explicitly not the goal of either project. For those workloads Ruby is already far down the list of best choices.
  - byroot 3y ago
    > Would you then agree that an event loop is very well suited for web server workloads, with short lived requests + reasonably light CPU usage + lots of IO, which happens to be the territory both Rage and Puma are situated? No, that's where I disagree. The average Ruby web application isn't as IO heavy as people claim, and often contains big chunks of CPU work (typically HTML templating or JSON generation/parsing) that run havoc in an event loop. My measurements on dozens of Rails app showed the IO ratio tend to be in the 30-70% range. Most closer to 50%. The apps that do more IO than that either have terribly optimized DB queries, or are mostly acting as some sort of HTTP client for an API, but from my experience that's the exception, not the rule. > For those workloads Ruby is already far down the list of best choices. Raw speed is far from the only criteria when one chose a stack...
    - thaosdfjw 3y ago
      That's interesting. Does that mean the typical Ruby workload would be a better match for userspace preemptive threads like BEAM?
      - dang 3y ago
        Could you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comment&storyText=false&prefix&page=0&query=community%20identity%20by:dang https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...