Running Ruby 3.2's YJIT in Production at Discourse

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

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!


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.


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


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


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


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


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

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