6 ms·
JIT doesn’t seem like the big optimization that Rails needs. Rails has low throughput because you have to run multiple full-fat instances of rails to handle req
by sosodev 5y ago
JIT doesn’t seem like the big optimization that Rails needs. Rails has low throughput because you have to run multiple full-fat instances of rails to handle requests in parallel or multiple beefy threads to handle requests concurrently. Either way you’re spending a huge amount of ram to add a small amount of throughput.
JIT only adds a marginal improvement to this current setup.
A true async backend like Falcon adds a huge amount of concurrent throughput if tuned correctly and ractors could provide a big parallelism boost if they shared more memory.
- StreamBright 5y agoI 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.
- 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.
- rattray 5y agoTIL 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 also that in Rails v5+, `config.allow_concurrency` is enabled by default, so Falcon works with it out of the box. Neat. Looks like Falcon's [benchmarks](https://github.com/socketry/falcon-benchmark#results https://github.com/socketry/falcon-benchmark#results) show 250+ concurrent connections serve with an order of magnitude less latency and 2-3x the RPS of puma or passenger, and >10x that of unicorn. Seems worth a look for anyone running Ruby in prod with really any concurrent traffic.
- alberth 5y agoIsn’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 agoAsync 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 agoI 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 agoThe fiber scheduler solves this as concurrent execution is now built into the core of Ruby 3.
- Conlectus 5y agoI don't follow how an "async backend" would help over threads in this case. If you mean using actors everywhere and moving that into client code, you effectively have a new framework. Likewise, async IO has high throughout but often trades that off for increased latency jitter, since requests can block each other because of the limited thread pool. This is less a problem with threads because of preemption (though they of course compete for shared resources like database time).
- merb 5y ago?! > This is less a problem with threads because of preemption (though they of course compete for shared resources like database time). eh, just because ONE implementation of async is single threaded, does not mean that others aren't. basically you trade of latency because most async implementations do SCHEDULE their tasks/promises in a WORK STEALING fashion (overscheduling and stuff) and another tradeoff is context switching, of course not all task implementations try to reduce that. also if you have blocking operations it might happen that you have two tasks/promises on the same thread, which are lightweight at the beginning and at the end the blocking operation might block the other promise (thus latency for b is reduced) with threads you MIGHT have higher latency in p50, but probably not in p99. of course if you have 16 threads and only 16 requests at any time, the sync engine wins, but most often that is only the case in small applications with few users.
- aardvark179 5y agoI don’t think Rails is anywhere close to light enough for the memory overhead of threads to be the important limiting factor. For an async server or something like project loom to pay off you need the request processing to be light and the time to be dominated by IO which can either be explicitly converted to async IO and callbacks or implicitly turned into async IO by your language’s standard library (as we are doing with Java and Loom). In my experience even with a JIT Rails is spending a lot of time in all the layers of request processing, so it has limited throughout even when the actual IO is trivial. No async framework can save you from processing overhead like that. Note: I work on TruffleRuby and Project Loom.
- viraptor 5y agoIt really depends on your workload. In my case for example an app takes ~60% of time in Ruby code. Tweaking how the scheduling of the processing works will not affect it as much as speeding up the actual Ruby part. For someone else with a very thin API service, it may not matter much. My point is, you can't generalise "what rails needs". Different deployments will need different things.
- ciconia 5y agoRails has a tendency to turn an I/O-bound problem into a CPU-bound one. with those hundreds or even thousands of object allocations per request, and dozens of abstraction layers, no amount of async magic powder is going to save you. At the same time, fiber-based concurrency does look promising for lighter weight Ruby web stacks.