Discourse では、Shopify の Ruby on Rails インフラストラクチャチームが本番環境対応を宣言して以来、YJIT を採用することを熱望してきました。有望なローカルベンチマークを目の当たりにした後、2023 年 5 月初旬に一部のクラスターで Ruby 3.2 の YJIT を有効にして本番 Rails アプリケーションを実行し始めました。その後、その実世界のパフォーマンスを測定する時間を費やしました。観測された肯定的な結果を共有できることを嬉しく思います。これらの調査結果に基づき、現在、すべてのホスティングで YJIT を有効にしており、セルフホスティングユーザーも同様にオプトインできます。
Discourse+YJITのベンチマークを22年11月から開始し、今年1月頃からMetaをYJITでオンオフしながら稼働させてきました。YJITは、数ヶ月でRuby 2.7からRuby 3.2へのアップグレードを加速させた理由の1つであり、ついに実現したことに興奮しています。さらに、Ruby 3.3で導入される改善はさらに良さそうなので、なおさらです！
Ruby の開発は非常に印象的ですね… 最近はクールな子たちはみんな Python にいると思っていましたよ？！ 
Ruby のロードマップについていくチームの皆さん、よく頑張りました。
おそらく愚かな質問かもしれませんが、「コンテナ定義ファイル」とは app.yml ファイルのことですか？このような呼び方を聞いたことがなかったので。ありがとうございます！
はい、その通りです。一部のユーザーが「app.yml」という名前を変更したり、複数のファイルを持っている可能性があるため、長い名前を使用しました。
JITを搭載したRuby 2.7と3.2の比較は非常に興味深いでしょう！
1月4日のメモより：
今実行しました
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から3.2 + YJITのスピードアップ
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
そして、測定されたデータがなく、単一または少数のユーザーの感覚や見解に基づいています。
私のフォーラムはしばらく前から遅くなっています。トピックを開くたびに、ほとんどの場合、短い間スピニングサークルが表示されます。もちろん、これはサーバーと米国とヨーロッパ間の距離に起因する可能性が高く、実際にそうでしょう。しかし、Metaは以前よりも遅くなっています。
私のフォーラムでYJITを使い始めましたが、サーバーがドイツにあり、ユーザーがフィンランドにいる場合、誰もがすべてのトピックがより速く開くと述べています。純粋な読み込み時間が200ミリ秒未満の変化を見ることができないことを考えると、これは実際にはかなり面白いです。
固定された（または一貫した）ページ読み込み時間について、しばらく考えてきました。すべてのページとすべてのユーザーの読み込み時間が可能な限り一貫していることです。
フィンランドのユーザーに関する情報は興味深いですね。これは、応答時間を節約するために、GEO IPまたはレイテンシーに基づいてユーザーを異なるサーバーにルーティングできるかどうか疑問に思いました。
これはDBアクセスを含まない結果ですか？
exiges.com でこれを有効にしました。
ベンチマークはしていませんが、トピックやスレッドが開く方法に違いがあることは確かです。
ユーザーから他に何も言われていないので、これは良いことだと思います 
はい、タイミングではDBクエリとRedisコマンドを除いたRubyコードの実行時間のみを測定しています。
