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 のタイムアウト時間を長くしてましたが、いつのまにか RailsFrameworkSpawnerIdleTime と RailsAppSpawnerIdleTime という 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 の設定に１行追加すれば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 のデフォルト設定でもいいかと思うぐらい。

A small pitfall on Mac with Capistrano's deploy:web:disable task

To test a deployment process of a rails application at my local machine, a Mac OS X Leopard, I set up virtual host with Apache + reverse proxy + mongrel. When I tried to do "cap deploy:web:disable", I fell in to a pitfall, a Mac OS X local issue. The apache constantly respond "403 forbidden" for every URL under the virtual host.

The things is...

1. Capistrano uses "/system/maintenance.html" for the path to the maintenance page (by the default)


2. And if you use Apache mod_rewrite, the setting about maintenance.html may look like this:
   

   
    RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
    RewriteCond %{SCRIPT_FILENAME} !maintenance.html
    RewriteRule ^.*$ /system/maintenance.html [L]
   



3. But, "RewriteRule" searchs the root of the file-system for "/system/maintenance.html" first (See description about "URL-path" of RewriteRule)


4. Yes, there is the directory "/System" on Mac OS X, and HFS+ doesn't matter case of filename


5. "/System" aren't accessible with httpd except you are mad


6. So, you get "403 Forbidden"

A alternative of the rewrite rule is:

 RewriteRule ^.*$ %{DOCUMENT_ROOT}/system/maintenance.html [L]

It works on Mac OS X (and other systems as well I think).