Passenger(mod_rails)の速度を計ってみた

ウワサのPassenger(mod_rails)を試してみました。
インストールのやり方はあちらこちらのサイトに書かれているし、すごく簡単(しかも親切)なので問題はないと思います。
ぼくとしては速度が一番気になっていたのでabで計測テストをやってみました。

ab -n 500 -c 2 http://milook.kaeruspoon.net/ 

テスト対象はmilookを使います。同時接続数が2と少ないのは、サーバ上でThinのプロセスが2個しかないからです。
kaeruspoon系のwebアプリはすべてThinで動いているので、まずはThinで計測してみました。

1. Apache2 + proxy_balancer + Thin(0.8.1)

Requests per second:    1.03 [#/sec]  

1. Apache2 + proxy_balancer + mongrel(1.1.5)
   つづいて、たぶん今一番一般的な構成のmongrelを試してみます。

Requests per second:    1.00 [#/sec]  

やっぱりThinのほうがちょっと速いね。

1. Apache2 + Passenger(1.0.5)
   いよいよPassengerです。

Requests per second:    1.04 [#/sec]  

お、Thinよりもさらに速い!(微妙だけど)

この結果を踏まえて、kaeruspoon系のwebアプリはすべてPassengerで動かすことに決めました(もうPassengerで動いています)。
PassengerのためにGCを改良した Ruby Enterprise Editionを使うとさらにメモリ消費量も抑えられるとか。今後試していこうと思います。
今回のテストではメモリ消費まではチェックしていません。 こちらの方の記事を読むかぎりでは、けっこうよさそうです。

ちなみに、PassengerではApacheのプロセスのほかにSpawnサーバ(スポーンと読むみたい)のプロセスも立ち上がります。
これはRailsフレームワークのコードをキャッシュしてくれるやつだそうです。それから、webアプリのコードをキャッシュしてくれるやつも別に存在します。Railsのバージョンが同じなら、複数のアプリがひとつのキャッシュを共有してくれるようにできているみたい。

Passengerを試していて一番気に入ったのが、mongrelやThinみたいに別個にwebサーバを立ち上げる必要がないところ。proxy_balancerも使わなくていいし。Apacheを頼りにできるのが精神的にかなり楽です。

追記:かえるイメージだけはPassengerでうまく動かなかったのでThinに戻しました。どこが悪いのかよくわからないな。まあ、そういうこともあるということで、シビアなサービスで使うにはまだまだ様子見なのかもしれません。

さらに追記:うまく動かなかった理由がわかりました。 ImageScienceを使っているRailsアプリをPassengerで動かすとエラーになるときの対処を参照。