Mongrel2を使用する理由
名前を1つしか付けられない場合、それはMongrel2はZeroMQを中心に構築されますです。これは、Webサーバーのスケーリングがかつてないほど容易になったことを意味します。
リクエストが届くと、Mongrel2がそれを受け取ります（ここでは、NginXや他のhttpdと同じように、異常なことはありません）。次に起こることは、Mongrel2がcompileのタスクをn個の（ZeroMQ対応の）バックエンドへの応答を分散し、それらが作業を行うのを待って、受信することです結果、応答をコンパイルしてクライアントに送信します。
今、魔法はnが任意の数であり、nのそれぞれがZeroMQ（20程度）でサポートされている任意の言語で記述できること、そしてすべてがネットワークを経由して各nを専用のボックスにすることができるという事実にあります、おそらく別のデータセンターにあります。
言い換えると、NginXとその他すべてのロジック層でスケーラビリティを実行する必要がある場合、Mongrel2を使用すると、リクエストをインフラストラクチャにヒットさせるところから（リクエスト/レスポンスサイクルの観点から）この権利をhttpdではなくhttpdではなく開始できます。複雑さをロジック層まで浸透させ、複雑さを少なくとも1桁増加させます。
それぞれの長所を確認し、ユースケースに応じてどちらかまたは両方を使用することを決定する必要があります。
Nginxはmongrel2が表面で提供するすべてのことを行うようですが、2つの間に焦点の大きな違いがあることがわかります。
NginxはフロントエンドWebサーバーとして優れており、リクエストをバックエンドWebサーバー/アプリサーバーにプロキシし、静的コンテンツを提供することもできます。
Mongrel2はスタックのわずかな変更です。言及したように、それのパワーは、それとバックエンドappserversの間のトランスポート層としてのzeromqの使用に由来します。動的リクエストURL（アプリリクエスト）を提供し、zeromqを使用してタスクの計算部分を別のバックエンドに送信できます。mongrel2を使用すると、http、websocketsなどだけでなく、他のプロトコル（提供する傾向がある場合）を提供できます。 ）すべて同じサーバーから。ユーザーは、アプリの一部がさまざまなバックエンドから提供されていることを決して知りません。
Webアプリケーションの機能に対する要件が変化し続ける場合、またはストリーミング、バックエンドでさまざまな言語でコーディングする機能などを追加したい場合は、間違いなくmongrel2を調べます。または、静的ファイルとキャッシングにnginx/haproxy/varnishを使用するハイブリッドもあり、それ以外はすべてmongrel2に転送されます。