[JohnBooty]

    Does anyone have any experience rolling it out? 

FWIW, the linked article has prod benchmarks.

    I'm pretty sure (there isn't a lot of info on how 
    to enable it in production workloads) we're running 
    YJIT in production

Sure you're running it? You have to compile with YJIT support, and then pass the command line arg. (It doesn't support YJIT out of the box because, I presume, they didn't want to force a Rust dependency on everybody?)

Here's how on MacOS + asdf, others will be similar. Note that I think --enable-yjit might work (but do nothing) even if you don't have support compiled in.

    # if you already installed 3.2.0
    asdf uninstall ruby 3.2.0
    
    # install Rust
    asdf plugin-add rust
    asdf...      
    
    # now install Ruby 3.2
    asdf plugin-update ruby
    export RUBY_CONFIGURE_OPTS=--enable-yjit
    asdf install ruby 3.2.0
    asdf global ruby 3.2.0

    # verify it's installed and ready
    ruby --enable-yjit --version

    # now run your workload
    ruby --enable-yjit foo.rb

[erikrothoff]

Yes, I'm pretty sure because:

1. Compiled with jyjit confrmed (ruby --yjit) returns the correct value

2. RubyVM::YJIT.enabled? returned true

But the information available on how to confirm YJIT is running is not super clear. Since I didn't notice any improvements I started wondering.

[JohnBooty]

Sounds like you're running it!

    Since I didn't notice any improvements I started wondering. 

It only speeds up Ruby itself. In a "real world" web app performance, performance is mostly dominated by Ruby/PHP/Java/whatever sitting around and waiting for database queries to execute.

So for a lot of web workloads the perf increase won't be huge. If your average endpoint is e.g. 5ms of Ruby and 500ms of DB queries, your max speedup will be negligible if you switch to YJIT... or even if you rewrite the whole app in hand-optimized assembler.

(Also gets to the root of why perf-based criticism of Ruby is usually dumb, IMHO. It's usually not the problem)