John Wellsは最近技術評価をしている間に、開発コミュニティに対して"Grailsの全てに関するベンチマークはどこにある?"と大声で質問した。
.. 私はGroovyと、JVM上で動く競合相手(JRuby、BeanShell、Jython)や一般的な動的言語(Ruby、Python、Perlその他)を比較した単一のベンチマークを見つけることができません。そしてまたGrailスタックとJRuby on Rails、Ruby on Rails、素のHibernate/Spring(Grailsは裏で多少使用している)等を比較したベンチマークも見つけることができません。
これの応答として、Grailsコミュニティは、Grails対Railsにおけるいくつかの大雑把な科学的でない数値を投稿した。ベンチマーク結果の中に混じって、以下のことが記載されている。
[読み込みのパフォーマンスに関して]...Grailsは、Railsが32リクエスト/秒を処理できるのに対し40リクエストを処理できます。重要なこととして、Grailsはワーストケースにおける応答時間がより悪いのに、平均応答時間が優れているとされていることに気づくでしょう(「平均時間」とは、 1000リクエスト全てにおける、1リクエストあたりの平均時間を意味しています)。これはJavaのスレッドモデルと、Tomcatのスレッドプールにおいて利用可能なスレッド数を超えて同時にプログラムが走ってしまい一瞬ブロックしたことが、原因となっている可能性があります。単にこれは、何よりもアーキテクチャの差異を反映している...[レコード作成に関して]...Grailsは140リクエスト/秒を受け付け、リクエストを平均 345ミリ秒で処理しています。比べてRailsは35(.5)リクエスト/秒と1.3秒/リクエストです。リアルなプロファイリングは一切無しですが、この理由はHibernateのセッションベースのモデルに大きく起因していると確信しています。Hibernateが複数の更新を終わりにまとめてバッチ実行するのに対し、ActiveRecordにおけるsave()の各呼び出しは即時永続化操作を行います...
[検索クエリに関して]...結果は非常に似通ったものになっており、真にデータベースのパフォーマンスに依存しています。注目に値するのは、Grailのワーストケースは、スレッドプールにおけるブロッキングによって良くない結果になっていますが、全体の平均時間は5.387ミリ秒で、Railsの6.386ミリ秒よりも優れていることです。これがRailsの7.65リクエストに対してGrailsは8.92リクエスト/秒を扱う事ができる理由の説明となっています...
この記事の締めくくりに、作者たちはRailsパフォーマンスチューニングの専門家ではないこと、Railsの最適化に対する提案は歓迎するということをはっきり述べている。これら実施されたテストは、Grailsのユーザたちに統計として伝えるだけのもので、決定的なベンチマークと言うわけではないのだ。
Railsコミュニティはベンチマークデータについて沈黙してはいない。Rails開発者とMongrelユーザは、記事のレスポンスの中でJared Richardsonのコメントに注目してみてほしい。
（原文は2007年3月23日にリリースされた記事です）... 新しいリクエストが来るたびにアプリケーションがインスタンスやスレッドを作成してしまっては、簡単にサーバは潰れてしまいます。Railsは他のアプローチを取っています。Rails開発者はあなたに望むのは、アプリケーションがどれだけのリソースを必要とするのかを意図した決断を行って欲しいということです。... 従って、RailsアプリケーションをMongrel上にデプロイしたら、どれだけのインスタンスを利用可能にするか決める必要があります。これが"マシンが応答しなくなるまでスレッドを廻し続ける"に似て見える、伝統的なTomcatモデルと決定的に違うところです。... 私がこの(ベンチマークの)ページをきちんと読めているなら、このベンチマークは単一のMongrelインスタンスで実行しており、それはJavaでシングルトンサーブレットを作りそれでテストしたというのに似ています。もちろん、それは非常に遅くなります ... 現実的な比較を行うためには、私はApacheのロードバランサプラグインか、私が個人的に好きなPoundを試します。