Verboseモードでいこう

Mongrelはいくつ立てるべき？

（2008年10月28日 Mark Reynolds）

あなたが作ったRailsアプリケーションがリリース直前だとします。アプリケーション層のサーバの構成を決めなければなりません。この様な場面において、FiveRunsでよく聞かれるのは「Mongrelをいくつ立てるのが得策でしょうか？」という質問です。これにはたくさんの意見があるでしょうし、読者自身にも考えがあるかもしれません。ですので以下の文章については、遠慮なくコメントしてください。

テストの実施

かなり以前からZedは、httperfをつかってパフォーマンステストを行い、Mongrelの数をその環境で最適な数まで増やすことを薦めています。ファイルを直接Webサーバからアクセスした場合と、アプリケーションをひとつのMongrelプロセスで走らせてアクセスした場合をテストします。これにより静的ファイルの実際のチェックを行い、Mongrelプロセスを増やすことでどのくらいまでレスポンスが良くなるかのベースラインを策定することができます。

1より大きい任意の値

サーバに搭載可能な物理的メモリ容量には上限があるため、Mongrelプロセスごとのメモリ消費量とシステムに積んでいるメモリ量によって答えは変わってきます。キューのバランシングを行うために最低2つのMongrelプロセスを立て、ひとつのMongrelがロックしてアプリケーション全体が止まってしまうことを避けようとする管理者は多いようです。エントリーレベルの256MBの仮想マシンで行った私のテストにおいては、フロントエンドがApache2の場合で3つのMongrelインスタンスを走らせた場合のパフォーマンスがベストでした。

弊社では

弊社の顧客の場合、8GBの物理メモリを積んだマシンでひとつのRailsアプリにつき5つ、1台のサーバにつき12個くらいのMongrelプロセスを立てるのが平均的な値です。これはFiveRunにおいても同様です。これは例えば、2つの大規模なアプリケーションにはそれぞれ5つずつのMongrelを立て、小さなRailsアプリには2つのMongrelというようなケースです。Nginxのような軽いフロントエンドは、プールしていたハードウェアをアプリケーションサーバとして随時追加するような場合でも、トラフィックをMongrelの使用ポートにバランシングしてくれます。

回答なし

「Mongrelはいくつ立てるべき？」という質問には答えないという選択肢が最適になりつつあります。Passengerはフロントエンドとアプリケーション層の間でポートをうまくハンドリングし、バックエンドプロセスの数も最適化してくれます。Thinは軽量かつ馬鹿みたいにインストールと設定が簡単です。これら2つはいずれ劣らぬパフォーマンスを発揮します。EbbもMongrelを大きく上回るパフォーマンスを実現しています。

その設定の容易さとパフォーマンスの高さから、今日わざわざMongrelを選ぶ理由はなくなっています。皆さん（私もですが）FastCGIやlighttpdに今もまだ満足できるでしょうか？　コミュニティでこれらを採用している例を見ることがあるかもしれません。でもそれはあなたの既存のシステムの正しさの証明になるでしょうか？