3 ms·
I started working with Ruby almost two decades ago and I can confirm that, in fact, Ruby is slow. It might be fast enough to make it viable for most web apps, b
by drogus 4y ago
I started working with Ruby almost two decades ago and I can confirm that, in fact, Ruby is slow. It might be fast enough to make it viable for most web apps, but compared to Go or Rust it will be much harder to write a fast app in Ruby. I've seen tweets and articles like this one (it's the databse not Ruby!) numerous times and it usually doesn't map to reality, especially in bigger applications. Of course you can make Rails to respond in milliseconds, but in real production apps I've usually seen 50-80% of the responses time to be spent in CPU (ie. Ruby). At the same time when the app grows and you add more middleware an empty response can easily take 5-10ms with a bit of a traffic (like: an empty controller action, no database queries etc). It's better with smaller frameworks like Sinatra, but still you can make the database much faster than the Ruby code making queries
update:
Maybe out of curiosity I'll make some benchmarks later, but even if you look at frameworks benchmarks you can see that for the same database queries there's an order of magnitude of difference between Ruby and Rust or Go frameworks: https://www.techempower.com/benchmarks/#section=data-r21&test=query https://www.techempower.com/benchmarks/#section=data-r21&tes... (look at latency)
- byroot 4y agoWhile I agree with your general point (yes a Ruby web app once basic database access patterns have been optimized is essentially CPU/GVL bound), I'd advise caution when using things like techempower benchmarks of the benchmark game. Different languages receive very different levels of care in these, and from memory there was some big no-nos in the Rails benchmark. One I remember for instance is that they use redis as a cache but without a connection pool [0], and AFAICT they run puma with at least 5 threads [1], so they are very likely to content on that one Redis connection. That's just one of the many things I spotted when I looked at it a few months back. [0] https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Ruby/rails/config/environments/production.rb#L45 https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [1] https://github.com/TechEmpower/FrameworkBenchmarks/blob/542904f589b63322b8610b82583ce8fdde97f6d0/frameworks/Ruby/rails/config/puma.rb#L12-L13 https://github.com/TechEmpower/FrameworkBenchmarks/blob/5429... Edit: To add to my point, you linked to the "20 queries" benchmark, which is essentially: render json: 20.times.map { |i| World.find(i) } Somehow this average 260ms latency while the single query version average 8ms, so something definitely don't add up, since worst case scenario it would be 20x slower so ~160ms. Another evidence is that the "cached" version is also 260ms. And this is a dummy app barely doing anything, I've seen apps doing a ton more work in much less time.