Thursday, July 30, 2009

Passenger: Keeping ApplicationSpawner alive speeds up spawning an instance (updated)

前回 passenger プロセスの起動時間について書いたとき passenger のバージョンは 2.0.3 でしたが、あれから 9ヶ月、 2009-07-29 現在の最新バージョンは 2.2.4 になってます。

そのときは passenger の constants.rb を直接変更するという荒技で FrameworkSpawner と ApplicationSpawner のタイムアウト時間を長くしてましたが、いつのまにか RailsFrameworkSpawnerIdleTimeRailsAppSpawnerIdleTime という Apache の設定で変更できるようになってます。こいつらを 0 にすれば FrameworkSpawner は Apache を再起動するまで、 ApplicationSpawner は Apache を再起動するか、 touch restart.txt するまで持続します。

また、前回の記事 では Capistrano でデプロイしたときに (タイムアウトを延ばしているときは特に) ApplicationSpawner を KILL しないと古いデプロイの ApplicationSpawner がずっと残ると書いたんですけど、 2.2.0 の "Support for Capistrano-style deployments" により、 Capistrano 使ってても touch restart.txt で ApplicationSpawner が再起動するので KILL する必要は無くなりました。
(でも、2.2.0 から 2.2.2 までは 2.2.3 の "Fixed restarting of the ApplicationSpawner server" が修正されてなかったので worker process がみんなタイムアウトしている間に restart すると古い ApplicationSpawner が残っちゃってたみたいです。)

ちなみに、Apache 再起動直後の FrameworkSpawner も ApplicationSpawner もいないときと、 worker process だけ fork するときの速度をブラウザのページロード時間で測ると、(僕の環境では)5.6秒が1.0秒になるので、デフォルト設定で FrameworkSpawner がタイムアウトする時間30分に一度アクセスがあるかどうかわからないようなサービスではこの設定は必須かと思われます。

2009-7-30 10:00 追記


結論だけ言うと、 passenger-install-apache2-module を実行した直後に追加する apache の設定に1行追加すればOKです。

PassengerRoot /opt/ruby-enterprise-1.8.6-20090610/lib/ruby/gems/1.8/gems/passenger-2.2.4
PassengerRuby /opt/ruby-enterprise-1.8.6-20090610/bin/ruby
+ RailsAppSpawnerIdleTime 0

ApplicationSpawner が常駐することによるメモリ消費は僕の小さなアプリケーションREE を使っていれば private メモリで 25M 程度でした。これだけのコストでアプリケーションのレスポンスタイムの5秒ぐらいのロスが無くなるなら大歓迎でしょう。 Passenger のデフォルト設定でもいいかと思うぐらい。

No comments: