昨日はrackupの基本とコマンドラインオプションについて解説しました。今日もつづけましょう!
開発中のコードは.rb
に書かれたRubyのコードを編集します。rackupによって起動されたサーバは永続プロセスのため、最初に一度だけコンパイルされたRubyコードが何度も実行されます。コードの変更を反映するにはサーバプロセスを再起動する必要があり、面倒です。
ロード済みのファイルを監視し、変更があったらアプリケーションをリロードするためのRackミドルウェアRack::Reloader
が標準で付属しています。以下のように利用できます。
require 'foo-lib'
require 'foo-lib2'
app = lambda {|env|
# ... your app
}
use Rack::Reloader
run app
Rubyの組み込み変数$LOADED_FEATURES
に格納される、あらゆる読み込み済みのファイルの変更を関知して、アクセスのたびにリロードします。plackupのリロードオプションと違い、rackupした本体である*.ru
ファイルはリロードしない点にはご注意ください。
また、Rack::Reloader
は、デフォルトではファイルの最終更新時刻を検知してリロードしますが、その際10秒間だけ変更したファイルをキャッシュします。このキャッシュする秒数は変更可能です。
use Rack::Reloader, 20 # 秒数を指定
永続環境のRubyプロセスでモジュールやアプリケーションを読み直す場合、問題がおこることがあります。
Rubygemsとして提供されるshotgun
コマンドを利用すると、リクエストごとに子プロセスをforkして、そこでアプリケーションを読み直します。
shotgunコマンドの利用は簡単です。
> shotgun myapp.ru
アプリケーションのコンパイルがランタイムまで遅延され、新しいリクエストが来た際、新しい子プロセスをforkし、Rubyのレスポンスをパイプ上で返します。開発中には変更することのないgemなどはプリロードしておき、レスポンスのボトルネックにならないようにすることも可能です。
たとえば、アプリケーションがActiveSupportの全機能を使っているなら、
> shotgun -ractive_support/all myapp.ru
とすればリクエストごとに読み直すコードが減少するため、スピードアップが期待できます。