Ruby on Rails は、マルチスレッドの要求応答をうまく処理できません。少なくとも、ActiveRecord はそうではありません。
同時にアクティブな要求応答が 1 つだけであるという概念は、完了するまでに時間がかかるシェル コマンドをフォークする Web アプリケーションを作成する場合に問題になる可能性があります。
この種の設定について、あなたの意見を聞かせてください。Rails は、一部のアプリケーションには適していないのでしょうか?
また、Ruby on Rails の同時実行性に関しては、現在どのような状況ですか? ベストプラクティスは何ですか。欠点に対する回避策はありますか？
Rails は現在、単一の MRI (Matz Ruby Interpreter) Ruby プロセス内で同時リクエストを処理しません。各リクエストは本質的に巨大なミューテックスでラップされています。来たる Rails 2.2 をスレッドセーフにするために多くの作業が行われましたが、Ruby 1.8x で実行している場合、これによるメリットはあまり得られません。私は Ruby 1.9 にあまり詳しくないので、Ruby 1.9 が異なるかどうかについてコメントすることはできませんが、おそらくそうではないと思います。
この点で非常に有望と思われる領域の 1 つは、JRuby を使用して Rails を実行することです。JVM は一般にマルチスレッドに適していると認識されているためです。Sun Microsystems のArun Guptaは、最近の RailsConf Europe で、このセットアップに関する興味深いパフォーマンス数値を示しました。
Matz の Ruby 1.8 はグリーン スレッドを使用し、Matz の Ruby 1.9 はネイティブの O/S スレッドを使用します。JRuby や IronRuby など、Ruby 1.8 の他の実装では、ネイティブの O/S スレッドが使用されます。YARV (Yet Another Ruby VM の略) もネイティブ O/S スレッドを使用しますが、常に 1 つの Ruby スレッドのみが実行されるようにグローバル インタープリター ロックを備えています。
Neverblockを使用すると、プログラムの作成方法を変更することなく、ノンブロッキング機能を使用できます。これは実にエキサイティングなプロジェクトであり、Ruby 1.8.x で動作するようにバックポートされました (Ruby 1.9 のファイバーに依存しています)。PostgreSQL と MySQL の両方で動作し、ノンブロッキング クエリを実行します。ベンチマークがおかしい…
シェルで実行するものがページのレンダリングに必要ない場合 (たとえば、メンテナンス タスクなどをトリガーするだけの場合)、それらをバックグラウンド プロセスとして開始する必要があります。starling と workingling をチェックしてください。
これが状況に当てはまらない場合は、アプリ サーバーの複数のインスタンスが実行されていることを確認する必要があります。伝統的に、人々は Mongrel の複数のインスタンスを起動していました。しかし今、確実なセットアップを行う最も簡単な方法は、 Phusion Passengerを使用することだと思います。これは、実行するアプリ サーバーのインスタンス数 (最小および最大) を簡単に指定できる Apache モジュールです。残りは乗客が行います。そして、私の記憶が正しければ、リクエストをディスパッチするためのばかげたラウンド ロビンは実行されません。アビリティによると思います。
Ruby1.9は軽量ファイバーを追加しています。