> 1.27 million requests per second > 3TB/minute of traffic "rails doesn't scale"
[dead]
Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
61–70 of 158 posts
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#62TruffleRuby What's the current state of Shopify running TruffleRuby, given the tragic loss of Chris Seaton?
Is TruffleRuby compitable with Rails? If so, I wonder how much TruffleRuby would improve the performance and memory footprint.
Especially with native images, I wonder how that would turn out.
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#63Earlier quoted context omitted.
That kind of thinking is a bit flawed unfortunately. You might hit your peak for 20 minutes a day but you’ve provisioned your system for that temporary worst case for the entire day and other services are paying that penalty. If it’s the only thing you’re running, maybe. But in practice there are other things you want to run on the machine to improve utilization rate (since services are not all hitting their peak sim…
Theoretically virtual memory and swap solve this problem really well. The OS is free to write the unused pages to disc to let other programs use the real memory.
Swap is horribly expensive and most hyperscalars run their servers without swap and set per-process memory limits, automatically killing workloads that go above their threshold..
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#64Earlier quoted context omitted.
That kind of thinking is a bit flawed unfortunately. You might hit your peak for 20 minutes a day but you’ve provisioned your system for that temporary worst case for the entire day and other services are paying that penalty. If it’s the only thing you’re running, maybe. But in practice there are other things you want to run on the machine to improve utilization rate (since services are not all hitting their peak sim…
What if the other thing you're trying to run runs at the same time that your rails app is using peak memory? You have no choice but to have enough memory for peak load. But if you really do need to cheap out you can generally configure your app server to kill idle worker processes, or bounce them on a schedule to return memory to the system, and hope.
So that’s generally not very likely. You’re going to have some time of day effects that are shared but true “peak” tends to be service dependent rather than something all your services experience simultaneously from what I’ve seen (YMMV).
Killing “idle” processes is also extremely expensive because you have to restart the process, reload all state, and doing graceful handoff is tricky.
It’s good to have graceful handoff for zero downtime upgrades, but I still say having your allocator return RAM is the cheapest and easiest option and something good modern allocators do for you automatically.
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#65Earlier quoted context omitted.
Or they could have used something available in 2006, like C++, Java, .NET/C#, OCaml, Haskell, D.
C# in 2006 was a joke, probably worse than Rails in performance. This was the webforms era and old EF - meant for enterprise customers with a couple of hundred active users max... ASP.NET being a competitive/performant framework is a very recent development (since core basically which became usable past 2.0) Haskell, OCaml and D are niche languages, probably aren't mature enough now to use for a production system tha…
A joke is this comment.
All of them were faster and used less resources than a very slow interpreted language, by having JIT and AOT compilers, state of the art GC and great IDE offerings, even the niche ones had better tooling (Leksah and Merlin, versus nothing).
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#66Earlier quoted context omitted.
> And how many instances would be required if Go/Rust would have been used? Zero. Because Shopify would have waited until Rust came out in 2015, instead of launching in 2006, and they would never have gotten off the ground and been another failed techbro startup that instead of getting shit done, bikeshedded over languages. PHP and Ruby apps have generated far more revenues than all the Rust and Golang code combined.
Or they could have used something available in 2006, like C++, Java, .NET/C#, OCaml, Haskell, D.
> Or they could have used something available in 2006, like C++, Java, .NET/C#, OCaml, Haskell, D.
Going for .NET/C# would have likely limited anyone to using mostly Windows Server for their infrastructure. Not that it's a bad OS, but .NET Core was released only in 2016 and although Mono came out in 2004, sadly it never got the love it deserved and was rather unreliable (otherwise we would have seen way more cross platform development before .NET Core). Oh, also, turns out that LINQ (which is pretty cool) was only released in 2007, though that still puts them a bit ahead of Java I guess, although I can't comment on when it landed in Mono.
Going with Java would have meant using something like Java 6, whereas the first truly decent version (in my eyes) was Java 8, which came out in 2014. Of course, the older language version and runtime wouldn't be a huge issue, however projects like Spring Boot only came out in 2014 and before then most people would either use Spring, Java EE (now Jakarta EE) or a similar framework from back then. I've worked with both and it wasn't pleasant - essentially the XML configuration hell with layers of indirection that people lament.
I mean, either would have probably been doable, but it's not like other stacks are without fault (even the ones I cannot really comment on).
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#67Earlier quoted context omitted.
Or they could have used something available in 2006, like C++, Java, .NET/C#, OCaml, Haskell, D.
> Or they could have used something available in 2006, like C++, Java, .NET/C#, OCaml, Haskell, D. Going for .NET/C# would have likely limited anyone to using mostly Windows Server for their infrastructure. Not that it's a bad OS, but .NET Core was released only in 2016 and although Mono came out in 2004, sadly it never got the love it deserved and was rather unreliable (otherwise we would have seen way more cross pl…
Stackoverflow is doing just fine with Windows Server.
Java 6 would still blow the water out of Ruby's slow interpreter.
Being pleasant isn't relevant for performance.
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#68Earlier quoted context omitted.
Well, Shopify is investing in optimizing Ruby, so they believe Ruby was the component with the most opportunity for improvement. And the results are showing there was indeed lots of places where improvements could be made.
That's like saying the leading F1 team is investing in optimizing side mirrors, therefore they believe side mirrors are the component with the most opportunity for improvement. The fact is that performance oriented organizations optimize everything unless they have math telling them it isn't worth optimizing. The "weakest link" belief is pure conjecture
It's easy to believe (and probably true) that there are some low-hanging fruits in a place nobody looked at before.
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#69> 1.27 million requests per second > 3TB/minute of traffic "rails doesn't scale"
That's not on a per-host basis. Shopify's design is, quite fortunately, one that partitions really well, as each store is completely independent of each other. Each store can be assigned to one pod, each pod can have as many hosts as it takes to optimize the use of a database instance, and then you can add more pods as the need arises. Edit: to be clear, that's not to say Rails can't scale. It can. It's just that it…
>That's not on a per-host basis.
I'm sorry, but this is one of the silliest nit picks ive ever seen on this site. Of course 1 million rps and 3TB/s isn't coming from a single host. 3 TB/s is far beyond the throughput of any network I've ever seen, considered or thought of, short of maybe a data center (and I don't work in that domain). 1.3 million requests per second is far beyond the capacity of pretty much any hardware available right now.
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#70Earlier quoted context omitted.
> Or they could have used something available in 2006, like C++, Java, .NET/C#, OCaml, Haskell, D. Going for .NET/C# would have likely limited anyone to using mostly Windows Server for their infrastructure. Not that it's a bad OS, but .NET Core was released only in 2016 and although Mono came out in 2004, sadly it never got the love it deserved and was rather unreliable (otherwise we would have seen way more cross pl…
Stackoverflow is doing just fine with Windows Server. Java 6 would still blow the water out of Ruby's slow interpreter. Being pleasant isn't relevant for performance.
> Stackoverflow is doing just fine with Windows Server.
Good for them! I guess it mostly depends on what you want to build your platform around, what the constraints are and what developer skillsets are popular in your market.
> Java 6 would still blow the water out of Ruby's slow interpreter.
Probably! I do recall major GC improvements starting from JDK 8 onwards, though when compared to Ruby even the older versions would probably be decent: https://blogs.oracle.com/javamagazine/post/java-garbage-coll...
It would actually be fun if someone pulled out the old versions from back then and did some benchmarks, though maybe asking someone to build a full stack application in such a dated tech would be a tough ask, unless they're passionate about it!
> Being pleasant isn't relevant for performance.
If the discussion is just about performance, then that's true.
If we look at things realistically, then there's more to it - like using a tech stack that allows you to iterate reasonably quickly, as opposed to making your developers want to quit their jobs every time they have to debug some obscure Servlet related bug or to work with brittle configuration in XML (been there dozens of times), to the point where not as much could even get built in a given amount of time with a particular stack due to its challenges.
I do hate when people say that additional nodes are way cheaper than developer salaries, but they're also correct most of the time. Of course, there's also the humanitarian take to just not forget about the developer experience, otherwise we'd have written all of our web software in C++ even back then. It'd work really fast, but we'd have way less software in general.