Hacker News Reader

Comment by aledalgrande | Hacker News Reader

This is legend. Rails can be and is used in high throughtput scenarios, people who say it can't scale all think they are working at Twitter while they just wrote inefficient code.

It is true that spending time optimizing queries will give you more benefits than JIT though. CPU is not the bottleneck for most Web tasks.

View on HN

Yes, it can be used.

Yes, it is crazy inefficient.

At Wunderlist, we launched WL3 with something like 1K rails boxes on AWS, running a few services. During the launch, my fun was tracking when we reached user/box parity :-)

But it did work.

After a while, we replaced each of the hundred+ rails boxes per service with 2 Scala instances per service.

Also worked. No change for users.

The FP folks should be forever grateful to Ruby for making their languages seem fast in comparison.

At another company where I consulted, for a web content management system, the rails devs were super excited to get the performance up to slightly below one second per request.

We got much better than that 2 decades earlier, running a CGI-Bin (no fast-cgi, so complete restart on every request) that completely re-initalised its Oracle DB connection every time etc. On hardware that was a small fraction of the performance of today's boxes.

> the rails devs were super excited to get the performance up to slightly below one second per request

If that was the case then Rails was their least important problem.

At the prototyping stage back-and-forth with the client I write VERY rudimentary Rails code, n+1s be damned, but I don't remember ever seeing a second long request.

I guess it just depends on what your app does. At my previous job we were serving several million requests/day off about 15-20 rails instances on heroku

It is a giant red flag to hear someone talk about requests per day. A day has 86,400 seconds. If you had 3 million requests in a day, that's only 35 per second on average.

If you had 20 instances, that is under 2 requests per second per instance.

I don't know what each request does of course, but it might be worth asking if each one should really take a billion clock cycles to complete.

I don't know why the parent was downvoted. His point is valid - 2rps per instance is pretty damning.

At previous job, we ran a rails based 60M€/year photos album e-commerce with 6 backend devs and a dedicated servers fleet on 2 DC that costed less than one dev salary.

I think ORMs are part of the problem. By abstracting away SQL, it becomes really easy to write something that generates terribly inefficient SQL without realizing. It's easy to not realize it in small test environments with small test amounts of data, too.

Even a single n+1 query can really hose performance by burdening the entire database.

Nowadays in Rails-land there's lots of tools to manage that, [the latest](https://blog.saeloun.com/2020/02/25/rails-strict-loading-mod...) integrated into Rails itself.

ORMs can be bad, but it's not fair to blame them "just because".

I'm not so sure. My experience is that ORMs often discourage (or at least lessen the need for) getting a good grasp on databases and SQL because they abstract away a lot of fundamentals. Like any abstraction, there are obviously benefits too, but I do think it's reasonable to say that "makes it too easy to write sloppy/unperformant queries" is a real cost.

> My experience is that ORMs often discourage (or at least lessen the need for) getting a good grasp on databases and SQL

I agree knowing SQL is very important, even if you use an ORM, sometimes you might need to roll up your sleeves and write some SQL (not to even mention knowing how to EXPLAIN queries, use indexes, etc).

Nowadays most things are abstracted away. A similar thing happens with IDEs, if your IDE takes care of compiling and building everything for you, then you don't understand how everything works under the hood. Is that a bad thing? It depends.

If you show HTML to a junior JS dev he'll say it's React, lol. I think there's no way escaping the abstractions in modern times.

This is a popular trope, but in practice it's just as easy to do n+1 via your own abstractions where "items.each { |i| i.foo }" happens to do it too. Without any ORM involved. Everyone will do it sometimes and the question is only whether you're going to spot it before it causes an outage. (In many cases it will only cause a slight slowdown)

At least there are tools to warn you about n+1 automatically https://github.com/flyerhzm/bullet

Sorry I used to work for Amazon and we did not allow Rails to be exposed to external customers for performance reasons. I think what you classify as high performance is very different what I classify as high performance.

Btw. I haven't seen Rails or Ruby on this list in the top 50% for a while:

https://www.techempower.com/benchmarks/

I would prefer hard data as opposed to "this is a legend".

UPDATE:

Rails is number 399 out of 439, having 0.3% performance of the top frameworks in a plain text task.

I know, facts hurt.

That's just Amazon's policy, not some sort of fundamental constraint of Rails itself.

While it's true Rails will use more ram than other options for a given traffic level, many of us have scaled it just fine.

The techempower benchmarks aren't particularly useful for anything other than forum warrior style arguments. They don't really measure a realistic workload.

Your last sentence is entirely unnecessary.

I agree, HN needs less and less facts nowadays and more feelings about somebodies favorite tool or framework. The quality of comments are going below Reddit levels.

You are the one being emotional, and obnoxiously toxic at that.

Everything I said is factual. Many of us have built successful startups on rails. I'm a very pragmatic person in general and abhor the cheering and jeering dynamic you're actively courting in this thread.

Please don't perpetuate flamewars or tit-for-tat spats on HN. We're trying for something different here.

https://news.ycombinator.com/newsguidelines.html

Please don't perpetuate flamewars or tit-for-tat spats on HN. We're trying for something different here.

https://news.ycombinator.com/newsguidelines.html

Oh yeah? Want an example? Apple. https://jobs.apple.com/en-ca/details/200226089/ruby-on-rails...

That job is for writing tools. So... not that performance critical.

That specific job might be for tools. But open Apple Music in your browser and tell me what it is using?

No, I want facts like a reproducible performance test like Techempower.

GitHub uses Rails just fine. If it works for GitHub, it will most likely work for >90% of use-cases out there.

Did I write anywhere that Github does not use Rails or 90% of internet cannot be run on Rails?

Your biggest constraint is programmer productivity, not server performance.

Your concerns are further diminished ~ every two years. Please re-evaluate your assumptions on that timeline.

This position was established by the company that owns the one of the largest server farms in the world? Are they looking to save on a few x-large instances? Seems short-sighted to me.

Sub 50ms response times are very achievable with Rails.

Throwing another server at it is a very reasonable response. Especially when you want your team to remain productive in a cohesive, batteries included framework.

Plenty of real-world Rails examples to demonstrate this.

Here's some hard data: Amazon is one of the largest internet companies out there, and most of us don't need to write anything approaching that kind of scale. Not by a long shot.

Your assumptions in computing should be reevaluated every two years.

https://mobile.twitter.com/brandonhilkert/status/13973190133...

I still don't understand why you are downvoted.

The fact that it is being used at Shopify and Github doesn't make Ruby Rails Fast. It just means their Business Model fits its usage COGS. Especially true if you are a SaaS with low / no Free Tier or Non-Freemium model.

Now that Shopify are spending hundred millions on cloud it absolutely make sense for them speed up Ruby Rails. I just hope it wont end up being like Twitter.

Reply on news.ycombinator.com