Running Ruby 3.2's YJIT in Production at Discourse

AI-generated summary

tgxworld announced that Discourse has enabled Ruby 3.2’s YJIT compiler in production after observing promising benchmarks. Shopify had previously declared YJIT production-ready. In early May 2023, Discourse began running YJIT on some production clusters and measured real-world performance improvements, including 36-40% faster page loads. Based on these positive results, they have now enabled YJIT across all hosting. Falco added that Meta had also been testing YJIT since late 2022 and upgraded to Ruby 3.2 quickly to take advantage of it. Benchmark results showed 1.15-1.40x speedups across various pages. However, Jagster noted that Meta felt slower despite the metrics, perhaps due to geographic distance affecting response times. Ksec suggested routing users to different servers based on location to optimize performance. The improvements exclude database and Redis operations, measuring only Ruby execution time. Overall, Discourse and other sites have observed real-world performance gains from enabling YJIT on Ruby 3.2 in production.

At Discourse, we have been eager to adopt YJIT ever since Shopify’s Ruby on Rails Infrastructure team declared it production-ready. After witnessing promising local benchmarks, we began running our production Rails applications with Ruby 3.2’s YJIT enabled on selected clusters in early May 2023. We then spent some time measuring its real-world performance. We are excited to share the positive results we observed. Based on these findings, we have now enabled YJIT across all of our hosting, and self-hosters can opt-in to do the same.


This is a companion discussion topic for the original entry at https://blog.discourse.org/2023/05/running-ruby-3-2s-yjit-in-production-at-discourse/
21 Likes

We started benchmarking Discourse+YJIT since Nov '22, and started running Meta under YJIT on and off since January this year. YJIT is one of the reasons we speed up the upgrade from Ruby 2.7 all the way to Ruby 3.2 in a few months and I’m ecstatic that it’s finally here. And even more as the improvements that will land for Ruby 3.3 are looking even better!

14 Likes

The development Ruby is getting is pretty impressive … I thought all the cool kids were on Python these days?! :sweat_smile:

Well done Team for keeping up with the Ruby roadmap.

12 Likes

Probably a stupid question, but is the “container definition file” the app.yml file? I’ve just never heard it called this before. Thanks!

3 Likes

Yes, that is it. We used the long name as some people may rename or have multiple “app.yml” files.

5 Likes

Very interesting would be a comparison between Ruby 2.7 and 3.2 with JIT!

2 Likes

From my notes from January 4th:

Re-ran it just now

Ruby Server p categories home topic categories user home user topic user categories admin home admin topic admin
2.7.5 Unicorn 50 34 59 36 82 112 93 67 94 72
3.1.2 Unicorn 50 34 61 36 82 112 91 67 94 70
3.2.0 Unicorn 50 33 59 36 82 111 90 68 92 72
3.2.0 +YJIT Unicorn 50 25 42 29 67 89 77 58 76 56

2.7 to 3.2 + YJIT Speedup

Speedup categories home topic categories user home user topic user categories admin home admin topic admin
1.36 1.40 1.24 1.22 1.25 1.20 1.15 1.23 1.28

7 Likes

And without any measured data and based to what a single or few users feels and sees.

For me this forum has been slower a while now. I see spinning circle at short moment almost every time I open a topic. Sure, it can and almost surely comes from servers and distances between USA and Europe. But Meta is slower than earlier.

I started use YJIT on my forum and when the server is in Germany and users are finnish everyone says all topics open faster. That is actually quite funny because we can’t see changes of pure loading times under 200 ms.

1 Like

I have been thinking about fixed (or consistent ) page loading time for quite some time. Where the loading times for every page and every user is as consistent as possible.

The information on Finnish users is interesting, this got me wondered if we could route user based on GEO IP or latency to different server with different load just to save them response time.

1 Like

Are these results without counting DB access as well?

I have enabled this on exiges.com.

I have admittedly not benchmarked but I can tell a difference in the way that topics and threads are opening.

It must be a positive step as users have not informed me otherwise :slight_smile:

1 Like

Yes we are only measuring the time spent executing Ruby code excluding DB queries and Redis commands in the timings.

1 Like