NginxとMongrelが一緒に使用されていることについてよく読んでいます。誰かが私にそれらがどのように違うのか説明できますか?なぜ雑種が必要なのですか?Nginxを多くのRailsサーバーと直接通信させることが推奨されないのはなぜですか?
2 に答える
両方とも Web サーバーですが、焦点は同じではありません。
- Mongrel は基本的に、HTTP インターフェイスを提供する ruby アプリケーション サーバーです。リクエストを受け取り、Ruby コードに渡し、http で応答を返すという 1 つのことを行います。並行性やパフォーマンス関連の機能は処理しません。One mongrel は、リクエストを処理する Ruby プロセスが 1 つあることを意味します。
- Nginx は、パフォーマンスを目的としたフル機能の Web サーバーです。静的ファイルで高いパフォーマンスを発揮できますが、Ruby、Python、またはその他の言語を直接処理することはできません。これを行うには、FastGCI または他のアプリケーション サーバーへのプロキシに依存しています。
明確にするために、Rails アプリ自体は直接使用できるわけではありません。コンテナーと呼べるものが必要です ( http://rack.github.com/について読むことをお勧めします)。この場合は Mongrel です。Rails コンソールを実行すると、通常、Ruby の最も基本的な Web "アプリ" サーバーである webrick になります (これは標準ライブラリの一部です)。
では、なぜフロントで Nginx を使用するのでしょうか? Mongrel のみを使用することを考えてみましょう: ポート 80 でリッスンする mongrel インスタンスを起動します。たとえば、リクエストが完了するまでに 500 ミリ秒かかる場合、1 秒あたり 2 クライアントを処理できます。しかし、それだけでは明らかに十分ではありません。別の雑種インスタンスを起動しましょう。しかし、ポート 80 でリッスンすることはできません。これは、最初のインスタンスによって既に使用されており、それに対してできることは何もないためです。
そのため、ポート 80 を引き続きリッスンすることで、複数の Mongrel インスタンスを処理できるものが前に必要です。Nginx サーバーを投入すると、多くの mongrel インスタンスにリクエストを (プロキシ) ディスパッチし、より多くのインスタンスを追加してより多くのサービスを提供できるようになります。クライアントを同時に。
質問への回答に戻ると、NGinx をレール サーバーと通信させるということは、1 つまたは複数の Mongrel (または Thin / Unicorn、利用可能なサーバー) を起動し、NGinx に要求を渡す必要があることを通知することを意味します。Passenger の使用に続いて Rails サービスをホストするのは一般的なパターンです。Passenger は、基本的に Apache ワーカーが Ruby コードを処理する方法を提供します。
NginxとMongrelの違い
どちらも確かに HTTP サーバーですが、焦点が異なります。Mongrel は、主に Ruby ベースのアプリケーションを対象とした高速 HTTP サーバーです。Ruby コードで簡単に拡張できます。ただし、静的ファイルの提供はあまり得意ではありません。つまり、Apache や nginx よりも低速です。また、Rails はシングル スレッドです。つまり、リクエストの過程で (実際のレンダリングまでコントローラー メソッドを呼び出す)、mongrel はロックされます。
上記の Mongrel と Rails の欠点を回避するために、本番アプリで推奨される設定は、Apache または nginx のいずれかをメイン Web サーバーとして配置し、非静的 Rails ページの要求を受信した場合、これを数値に渡すことです。基礎となる雑種の場合、雑種がレンダリングされたページを Apache/nginx に戻し、そのページを画像/スタイルシート/などの静的ファイルとともに提供します...最初は少し困難で複雑に思えるかもしれませんが、実際に実装するとそれは、非常に強力で安定しています(1回の再起動なしでサーバー上で数か月から数年実行されているアプリがいくつかあります)。要するに、Apache/nginx に得意なことをさせ、mongrel クラスターに得意なことをさせれば、誰もが満足するということです。
Apache ではなく nginx を選択することは、主にメモリの考慮事項に基づいています。Apache は非常に重い Web サーバーです。特に、実際に静的ファイルを提供し、残りをたくさんの雑種に分散させるだけの場合はなおさらです。Nginx は非常に軽量でパフォーマンスが高く、Apache と同じように優れた機能を発揮します。ただし、Apache に慣れていて、nginx の構成を把握したくない場合や、サーバーに大量のメモリを使用したくない場合でも、Apache を使用できます。基本的な VPS では、nginx がより適切なアプローチです。
詳細については
Apache 対 Nginx
どちらも Web サーバーです。それらは静的ファイルを提供できますが、適切なモジュールを使用すると、PHP で記述されたものなどの動的 Web アプリケーションも提供できます。Apache はより一般的であり、より多くの機能を備えています。
Apache も Nginx も、すぐに使用できる Rails アプリを提供することはできません。これを行うには、Apache/Nginx を何らかのアドオンと組み合わせて使用する必要があります。これについては後述します。
Apache と Nginx はリバース プロキシとしても機能します。つまり、着信 HTTP 要求を受け取り、HTTP を話す別のサーバーにそれを転送できます。そのサーバーが HTTP 応答で応答すると、Apache/Nginx はその応答をクライアントに転送します。なぜこれが重要なのかは後で学びます。
雑種 vs WEBrick
Mongrel は Ruby の「アプリケーション サーバー」です。具体的には、Mongrel が次のようなアプリケーションであることを意味します。
- Rails アプリを独自のプロセス空間内にロードします。
- TCP ソケットをセットアップして、外部の世界 (インターネットなど) と通信できるようにします。Mongrel は、このソケットで HTTP リクエストをリッスンし、リクエスト データを Rails アプリに渡します。次に、Rails アプリは HTTP 応答がどのように見えるかを説明するオブジェクトを返し、Mongrel はそれを実際の HTTP 応答 (実際のバイト) に変換し、ソケットを介して送り返します。
WEBrick も同じことを行います。Mongrel との違い:
- それは完全に Ruby で書かれています。Mongrel は Ruby のパート C の一部です。ほとんどが Ruby ですが、その HTTP パーサーはパフォーマンスのために C で書かれています。
- WEBrick は遅く、堅牢性に欠けます。いくつかの既知のメモリ リークといくつかの既知の HTTP 解析の問題があります。
- WEBrick はデフォルトで Ruby に含まれているため、通常、開発中のデフォルト サーバーとしてのみ WEBrick が使用されます。Mongrel は別途インストールする必要があります。実稼働環境で WEBrick を使用する人は誰もいません。
同じカテゴリに分類される別の Ruby アプリケーション サーバーは Thin です。内部的には Mongrel と WEBrick の両方とは異なりますが、使用法とサーバー スタックでの全体的な役割に関しては同じカテゴリに分類されます。