RubyKaigi 2023に参加した結果、RailsのYJITを有効化しパフォーマンス向上した

STORES 予約でエンジニアリングマネージャーをしている natsume です。

今回はRubyKaigi 2023に参加して「うぉぉなんかやるぞぉ！」となった結果、STORES 予約のバックエンドであるRailsアプリケーションをYJIT有効化しパフォーマンス向上できました。

動機からわかるとおり、YJIT有効化までノリと勢いでやりました。

影響されたセッションはDAY2のKeynoteである Optimizing YJIT’s Performance, from Inception to Production です。（影響はされましたが内容は全然わからなかった。英語勉強する、絶対） rubykaigi.org

有効化の手順

STORES 予約ではすでにRuby 3.2を利用していたのでかなりサクッとできました。

Debian(slim)を利用しているので、そちらのImageでYJITがサポートしているか確認します。

docker run -it ruby:3.2.2-slim ruby --yjit -e 'p RubyVM::YJIT.enabled?'
true

問題なく使えました。

ちなみにこちらのPRにてDebian対応がされています。 github.com

RUBY_YJIT_ENABLE=1 をセットするとYJITが有効な状態でRubyが実行されます。

STORES 予約はECSで動いており、環境はDockerfileで作っているのでそこに環境変数を入れていきます。

+ ENV RUBY_YJIT_ENABLE=1

ちなみに、dotenvなどで環境変数をセットしてもRuby起動後に環境変数がセットされるので有効になりません（ちょっとハマりました）

BuildしたImageの中で ruby -v を実行するとYJITで実行されていることがわかります。

ad7108378f4d:/usr/src/app# ruby -v
ruby 3.2.2 (2023-03-30 revision e51014f9c0) +YJIT [aarch64-linux]

その後Stagingで問題なく動くか確認をしました。

Ruby3.1から3.2でYJITのメモリ使用量はかなり改善したようですが、有効化することでメモリ使用量が増加することは見込まれます。

メモリ使用量には余裕があったので、気にしつつも大きな対応は不要でした。

STORES 予約のRailsではAPI以外にもSlimでレンダリングしてる部分もあります。それらを踏まえて見ていきましょう。

今回はYJIT有効化した前後で比較してサクッと確認しました。（前日比はバラツキが多く有意ではなかったので省いています）

Rack RequestのLatency Graphを見てみるとYJIT有効化した後に若干下がっていることが確認できました。P50だとわかりやすいですね。

さらに各項目のLatencyを比較してみました。

メトリクス		前	後	改善率
Rack Request	p90	102.3ms	95.2ms	7.46%
Rack Request	p95	169.1ms	158.8ms	6.49%
ActiveRecord Instantiation	p90	151μs	132μs	14.39%
ActiveRecord Instantiation	p95	288μs	247μs	16.60%
Render Template	p90	122.5ms	183.4ms	2.89%
Render Template	p95	188.7ms	123.6ms	-0.89%