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.
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) 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.
I 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.
It 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.
I 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).
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.
Rails 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.
I'm very much in favour of seeing performance as a key part of the development of any dynamic, interpreted language. (I single out dynamic languages because in most typed, compiled languages, fast execution speed comes for free.)
However, David Heinemeier Hansson, co-founder of Basecamp and creator or Ruby-on-Rails, has this interesting take on the cost of running Ruby for their business. Make of it what you will:
Only 15% of the Basecamp operations budget is spent on Ruby (2019)
I mostly agree with the argument, but it's worth noting that a faster runtime may itself results in cutting the other 85% of costs, i.e. you don't need to complicate your architecture to deal with performance issues, nor hire more ops people to manage more servers etc..
While I agree that the cost of "Ruby" gets dwarfed when running a larger business that uses it, I think it's really important to the larger ecosystem around Ruby that this low-level research/work happens.
It's also really great to see large companies like Shopify invest in such low-level things, and not just on gems/changes that directly touch their business.
Sure, that's a really important point, but if you get it mostly 'for free', you can - at the margin - expand the kinds of businesses where Ruby makes sense.
It is probably higher than that given your ORM / ActiveRecord Performance directly impact DB cost. But the point still stands at ~20%.
But again, it only works for specific type of Web Apps. Those that require lots of traffic to generate relatively smaller amount of revenue, running on Freemium model wouldn't work because your cost / user are far higher. And these Web Apps / Site power 90% of the internet.
Thanks at k0kubun and all the others investing their time to Ruby optimization.
When performance is a metric one needs to care about Ruby is a bad choice and will stay a bad choice.
I find C# with dotnet a very good framework that has amazing performance characteristics and also good developer tooling.
I coded many things with Ruby and Rails privately and as my daily job but nowadays it is mostly C# for webdev.
[+] [-] sosodev|4 years ago|reply
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.
[+] [-] rattray|4 years ago|reply
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) 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.
[+] [-] aardvark179|4 years ago|reply
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|4 years ago|reply
My point is, you can't generalise "what rails needs". Different deployments will need different things.
[+] [-] Conlectus|4 years ago|reply
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).
[+] [-] StreamBright|4 years ago|reply
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.
[+] [-] ciconia|4 years ago|reply
At the same time, fiber-based concurrency does look promising for lighter weight Ruby web stacks.
[+] [-] ksec|4 years ago|reply
MIR, coming from Vladimir Makarov ( RedHat ) again.
YJIT coming from Shopify, Dr Maxime Chevalier-Boisvert is leading the team and Dr Stefan Marr ( I think ) will be joining them soon.
TruffleRuby, with Dr Chris Seaton now also working in Shopify.
JRuby, Charles Nutter ( RedHat ).
[+] [-] tekknolagi|4 years ago|reply
[+] [-] an_opabinia|4 years ago|reply
Maybe everyone should be porting to V8.
[+] [-] multiplegeorges|4 years ago|reply
[+] [-] mchusma|4 years ago|reply
[+] [-] open-source-ux|4 years ago|reply
However, David Heinemeier Hansson, co-founder of Basecamp and creator or Ruby-on-Rails, has this interesting take on the cost of running Ruby for their business. Make of it what you will:
Only 15% of the Basecamp operations budget is spent on Ruby (2019)
https://m.signalvnoise.com/only-15-of-the-basecamp-operation...
[+] [-] riffraff|4 years ago|reply
[+] [-] multiplegeorges|4 years ago|reply
It's also really great to see large companies like Shopify invest in such low-level things, and not just on gems/changes that directly touch their business.
[+] [-] davidw|4 years ago|reply
[+] [-] ksec|4 years ago|reply
But again, it only works for specific type of Web Apps. Those that require lots of traffic to generate relatively smaller amount of revenue, running on Freemium model wouldn't work because your cost / user are far higher. And these Web Apps / Site power 90% of the internet.
[+] [-] The_rationalist|4 years ago|reply
[+] [-] hit8run|4 years ago|reply