8 ms·
I think in the context of high performance it is pointless to talk about Rails. Even the memory requirements make it impossible scale above a certain (very low)
by StreamBright 5y ago
I think in the context of high performance it is pointless to talk about Rails. Even the memory requirements make it impossible scale above a certain (very low) threshold.
In the context of developer productivity it is also pointless to talk about high performance because people sacrifice performance for developer happiness.
Once you understand that you have these two dimensions most frameworks are revolving around it is getting much clearer which one to pick for a certain use case.
- aledalgrande 5y agoThis 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.
- StreamBright 5y agoSorry 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/ 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.
- aledalgrande 5y agoOh yeah? Want an example? Apple. https://jobs.apple.com/en-ca/details/200226089/ruby-on-rails-engineer-apple-media-products https://jobs.apple.com/en-ca/details/200226089/ruby-on-rails...
- StreamBright 5y agoNo, I want facts like a reproducible performance test like Techempower.
- gosukiwi 5y agoGitHub uses Rails just fine. If it works for GitHub, it will most likely work for >90% of use-cases out there.
- StreamBright 5y agoDid I write anywhere that Github does not use Rails or 90% of internet cannot be run on Rails?
- google234123 5y agoThat job is for writing tools. So... not that performance critical.
- aledalgrande 5y agoThat specific job might be for tools. But open Apple Music in your browser and tell me what it is using?
- jasonwatkinspdx 5y agoThat'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.
- StreamBright 5y agoI 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.
- jasonwatkinspdx 5y agoYou 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.
- dang 5y agoPlease don't perpetuate flamewars or tit-for-tat spats on HN. We're trying for something different here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- dang 5y agoPlease don't perpetuate flamewars or tit-for-tat spats on HN. We're trying for something different here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- aantix 5y agoYour 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.
- davidw 5y agoHere'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.
- ksec 5y agoI 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.
- aantix 5y agoYour assumptions in computing should be reevaluated every two years. https://mobile.twitter.com/brandonhilkert/status/1397319013399613448 https://mobile.twitter.com/brandonhilkert/status/13973190133...
- nijave 5y agoI 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.
- gosukiwi 5y agoNowadays in Rails-land there's lots of tools to manage that, [the latest](https://blog.saeloun.com/2020/02/25/rails-strict-loading-mode-to-fix-n-1.html 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".
- whakim 5y agoI'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.
- gosukiwi 5y ago> 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.
- viraptor 5y agoThis 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 https://github.com/flyerhzm/bullet
- mpweiher 5y agoYes, 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.
- ativzzz 5y agoI 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
- CyberDildonics 5y agoIt 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.
- cutler 5y agoI don't know why the parent was downvoted. His point is valid - 2rps per instance is pretty damning.
- Toutouxc 5y ago> 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.
- whakim 5y agoI don't know what your definition of a "very low" threshold is, but it's much lower than mine. If you're Uber or Amazon, Rails isn't going to work for you. But that's fine because 99.9% of companies in existence don't fall into that category. I realize everyone wants to be the next <insert huge company here>, but the reality is a) you probably won't be; and b) given that you won't be, stuff like fixing poor caching strategies and inefficient queries are going to give you an order of magnitude more performance/buck than choosing <insert framework/language here> over Rails.
- aeontech 5y ago100% agreed. I'd also add c) if you _do_ end up getting close to hitting those limitations, you'll also have enough resources to rebuild the slow parts (and, chances are, you're going to end up rebuilding things five times over during your growth and scaling phase anyway, no matter what framework you had chosen).
- drewbug01 5y ago> I think in the context of high performance it is pointless to talk about Rails. Even the memory requirements make it impossible scale above a certain (very low) threshold. GitHub runs the vast majority of web requests through a giant Rails monolith; and they're not alone. I think calling it "impossible [to] scale above a certain (very low) threshold" is an uninformed opinion (and not supported by the evidence), to say the least.