Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
railsatscale.com
Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
1–10 of 158 posts
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#2 > 1.27 million requests per second
> 3TB/minute of traffic
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#315% faster is great. But at what cost?
> Since Ruby 3.3.0-preview2 YJIT generates more code than Ruby 3.2.2 YJIT, this can result in YJIT having a higher memory overlead. We put a lot of effort into making metadata more space-efficient, but it still uses more memory than Ruby 3.2.2 YJIT.
I'm hoping/assuming the increased memory usage is trivial compared to the cpu-efficiency gains, but it would be nice to see some memory-overhead numbers as part of this analysis.
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#4> 1.27 million requests per second > 3TB/minute of traffic "rails doesn't scale"
Rails scales fine. People use that as an escape hatch when they don't know how to write performant code.
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#515% faster is great. But at what cost? > Since Ruby 3.3.0-preview2 YJIT generates more code than Ruby 3.2.2 YJIT, this can result in YJIT having a higher memory overlead. We put a lot of effort into making metadata more space-efficient, but it still uses more memory than Ruby 3.2.2 YJIT. I'm hoping/assuming the increased memory usage is trivial compared to the cpu-efficiency gains, but it would be nice to see some me…
This is a particularly valid concern given ruby+rails seems quite memory inefficient to begin with. I've sometimes had smallish apps on 500mb heroku dynos crashing due to memory slowly climbing and eventually slowing things down as the dyno uses swap, and eventually 500mb of swap. IME ruby+rails doesn't seem to free up memory after it uses it, and that causes problems as the hours go by until the pod/dyno crashes or is restarted.
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#6> 1.27 million requests per second > 3TB/minute of traffic "rails doesn't scale"
What is the hardware spec here?
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#7> 1.27 million requests per second > 3TB/minute of traffic "rails doesn't scale"
You need the number of servers and server specs to answer that question.
Even if a piece of software could only handle 1 request per second you could handle 1.27M requests if you just run 1.27M servers.
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#815% faster is great. But at what cost? > Since Ruby 3.3.0-preview2 YJIT generates more code than Ruby 3.2.2 YJIT, this can result in YJIT having a higher memory overlead. We put a lot of effort into making metadata more space-efficient, but it still uses more memory than Ruby 3.2.2 YJIT. I'm hoping/assuming the increased memory usage is trivial compared to the cpu-efficiency gains, but it would be nice to see some me…
This is a particularly valid concern given ruby+rails seems quite memory inefficient to begin with. I've sometimes had smallish apps on 500mb heroku dynos crashing due to memory slowly climbing and eventually slowing things down as the dyno uses swap, and eventually 500mb of swap. IME ruby+rails doesn't seem to free up memory after it uses it, and that causes problems as the hours go by until the pod/dyno crashes or…
I’ve observed same, and every time I switched to jemalloc and the issue was fixed.
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#9> 1.27 million requests per second > 3TB/minute of traffic "rails doesn't scale"
These two points are entirely unrelated. Scaleability in that meme is not considering horizontal scalability, which approaches infinity for literally any language/framework. It only makes sense in the context of vertical scalability, and gross req/sec offers no insight into whether or not that's true.
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#10> 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 doesn't need to- you can scale anything with enough partitioning.