Skip to content

Latest commit

 

History

History
41 lines (24 loc) · 2.68 KB

04_reloading_applications.md

File metadata and controls

41 lines (24 loc) · 2.68 KB

Day 4: アプリケーションのリロード

昨日は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 # 秒数を指定

リロードがうまく動かない場合: shotgun

永続環境のRubyプロセスでモジュールやアプリケーションを読み直す場合、問題がおこることがあります。

Rubygemsとして提供されるshotgunコマンドを利用すると、リクエストごとに子プロセスをforkして、そこでアプリケーションを読み直します。

shotgunコマンドの利用は簡単です。

> shotgun myapp.ru

アプリケーションのコンパイルがランタイムまで遅延され、新しいリクエストが来た際、新しい子プロセスをforkし、Rubyのレスポンスをパイプ上で返します。開発中には変更することのないgemなどはプリロードしておき、レスポンスのボトルネックにならないようにすることも可能です。

たとえば、アプリケーションがActiveSupportの全機能を使っているなら、

> shotgun -ractive_support/all myapp.ru

とすればリクエストごとに読み直すコードが減少するため、スピードアップが期待できます。