ruby インタープリターを JRuby に更新することを検討しています。アプリから 2.x 固有の構文をすべて削除し、ruby 1.9.3 との互換性に頼らなければならなかったため、かなりの頭痛の種でした。それは世界の終わりではありません。
アプリを実行すると、クラスター モードで Puma を使用できないことがわかりました。問題は、過去数年間の MRI に対するすべての修正と変更を考えると、「実際のスレッド」を持つことの利点がまだ有効かということです。
アップデート
これをより客観的にするための質問は、「最新バージョンの MRI は、ネイティブ スレッドが提供するのと同じ利点を達成するために JRuby を採用する必要性を否定するか?」です。
最新バージョンの MRI では、ネイティブ スレッドと同じメリットを得るために JRuby を採用する必要がなくなりますか?
答えはノーだ。必要性を否定するものではなく、他の回答で述べたように、アプリケーションによって異なります。
また、JRuby ではクラスター モードで実行することはできませんが、マルチスレッドで並列であるため、質問に関しては実際には問題になりません。必要な数のスレッドを使用してシングル モードで実行するだけです。さらに軽量ではないにしても、それは完全に問題ないはずです。
より多くの洞察を与え、さらに掘り下げることができる参考文献をいくつか紹介しましょう。
この回答では、Puma (最大 40 スレッド) を使用して同時要求をテストする MRI および JRuby の実験について説明します。それはかなり包括的です。
実験は GitHub、MRI、およびJRubyで入手できます。
注意点は、同時リクエストのみをテストすることですが、コントローラーに競合状態がないことです。ただし、この記事のテストを実装できると思いますconfig.threadsafe を削除します! あまり努力せずに。
JRuby と MRI の違いは、JRuby がコードを並列に実行できることです。MRI は GIL によって制限されており、一度に実行できるスレッドは 1 つだけです。GIL の詳細については、この記事「誰も理解していないGIL」を参照してください。
結果は非常に驚くべきものです。MRI は JRuby よりも高速です。レース条件を自由に改善および追加してください。
どちらもマルチスレッドであり、スレッドセーフではないことに注意してください。実際の違いは、MRI はコードを並列に実行できず、JRuby はできることです。
実験で MRI の方が高速であることが示されている場合、なぜ「いいえ」と答えるかを言いたくなるかもしれません。
より多くの実験、特に実世界への応用が必要だと思います。
コードを並列実行できる JRuby の方が高速であると思われる場合は、次の理由が考えられます。
私見それはあなたのアプリケーションが何をするかによって異なります。
Rails アプリケーションで MRI/YARV と JRuby の両方をテストしました。アプリが行うことのほとんどは、HTTP 要求のルーティング、DB からのフェッチ、単純なビジネス ロジックの適用、および DB への書き込みであるため、並列処理はそれほど問題ではありません。MRI 上の Puma は、IO 操作 (DB、API) をブロックするためのマルチスレッドを処理します。この範囲外のタスク (画像処理、レポート データの処理、外部 API の呼び出しなど) は、おそらくバックグラウンド ジョブで処理する必要があります ( https://github.com/brandonhilkert/sucker_punchをお勧めします)。
展開のニーズによっては、メモリ消費がより問題になる可能性があり、JRuby はメモリを非常に必要としています。私の場合、ほぼ2倍のメモリ。
アプリケーションを Heroku にデプロイする場合、1 つの dyno で 2 つのインスタンスを同時に実行できるため、費用対効果が高くなることがあります。