私の会社が最終的に社内での使用を許可したので、私は最初の Ruby アプリを開発することに非常に熱心です。
v1.8 までの Ruby について読んだすべての記事で、パフォーマンスについて肯定的なことは何も言われていませんが、バージョン 1.9 については何も見つかりませんでした。私が最後に見た 1.8 の数字は、そこにあるすべてのものよりも大幅に遅かったので、1.9 でこれが解決されることを願っています。
パフォーマンスは大幅に向上しましたか？パフォーマンスを可能な限り最高のレベルに保つために、Ruby アプリで実行できる具体的なこと (または避けるべきこと) はありますか?
http://www.rubychan.de/share/yarv_speedups.htmlには、1.8 対 1.9 のベンチマークがいくつかあります。全体として、ほとんどの場合、1.9 の方がはるかに高速であるように見えます。
スケーラビリティとパフォーマンスが本当に重要な場合は、Ruby Enterprise Editionもチェックしてください。これは、Ruby インタープリターのカスタム実装であり、メモリ割り当てとガベージ コレクションがはるかに優れているはずです。JRuby と直接比較する客観的な指標は見たことがありませんが、私が聞いた事例証拠はすべて非常に優れています。
これはPassenger (別名 mod_rails)を作成したのと同じ会社からのもので、JRuby ルートに行かない場合は、Rails デプロイメント ソリューションとして必ず確認する必要があります。
Matz ruby 1.8.6 はパフォーマンスに関してははるかに遅く、1.9 と JRuby はそれを高速化するために多くのことを行っています。ただし、パフォーマンスは、Web アプリケーションで必要なことをすべて実行できないほどのものではありません。多くの大規模な Ruby on Rails サイトは、「解釈が遅い」言語で問題なく動作します。Web アプリをスケールアウトすると、言語の速度よりも多くの差し迫ったパフォーマンスの問題が発生します。
実際、JVM 実装である JRuby のパフォーマンスが非常に優れていると聞いたことがあります。完全に逸話ですが、おそらく調べる価値があります。
私は Ruby プログラマーではありませんが、最近 JRuby の展開にかなり深く関わってきたので、いくつかの結論を導き出すことができます。JRuby のパフォーマンスにはあまり期待しないでください。インタープリターモードでは、C Ruby の範囲のどこかにあるようです。JIT モードの方が速いかもしれませんが、理論上だけです。実際には、中規模のサーバー (デュアルコア、8GB RAM) 上の適切なサイズの Rails アプリケーションに対して、Glassfish で JIT モードを試しました。実際のところ、JITting には非常に長い時間がかかり、サーバーが最初のリクエストに応答するまでに 20 ～ 30 分かかりました。メモリ使用量は天文学的で、プロファイラーが接続されているとシステム全体が停止したため、プロファイリングは機能しませんでした。
結論: JRuby にはメリット (マルチスレッド、堅実なプラットフォーム、簡単な Java 統合) がありますが、インタープリター モードが実際に機能した唯一のモードであることを考えると、C Ruby よりも優れたパフォーマンスは期待できないかもしれません。
Addison Wesley Professional の「Writing Efficient Ruby Code」をご覧ください。
http://safari.oreilly.com/9780321540034
この短い作業で、非常に役立つ興味深い洞察を見つけました。また、10 日間の無料トライアルにサインアップすると、無料で読むことができます。(これは 50 ページで、トライアルでは (AFAIR) 100 ページ ビューを取得できます。)
Passenger を使用することをお勧めします。これにより、Rails アプリケーションの展開と管理が簡単になります。