UnicornをNginx（またはApache）の背後に置く必要がありますか？

Question

私はこのアーキテクチャについて少し混乱しています。私が取り組んでいるプロジェクトの1つでは、UnicornがRailsサーバーとして選ばれました。そしてそれはNginx Webサーバーの後ろに置かれます。 Unicornが完全に機能するWebサーバーであると理解しているので、同じサーバーインスタンス上に他のRailsアプリケーションをホストする予定はありません。

だから私の質問は次のようになります。チェーンに追加の層を持つことのメリットが何であるか：

client -> nginx -> unicorn -> unicorn worker 

Answer 1

ユニコーンが「遅いクライアント」を処理するように設計されていませんでした。あなたはPHILOSOPHYヘルプファイルにこの詳細を読むことができます：私たちが見てきた

ほとんどのベンチマークは、あなたにこのことを教えていない、とユニコーンが遅いクライアントを気にしない...しかし、あなたはする必要があります。

「低速クライアント」は、データセンター外の任意のクライアントにすることができます。ローカルネットワーク内のネットワークトラフィックは、ローカルネットワーク内を横切るトラフィックよりも常に高速です。物理学の法則は他には許されない。

HTTP/1.1で永続的な接続が導入され、接続の確立とTCPのスロースタートからの待ち時間が短縮されました。また、クライアントがアイドル状態のときにサーバーリソースを浪費します。

永続的な接続は、ユニコーン作業者プロセスの1つを意味します（アプリケーションによってはメモリが非常に浪費されることがあります）。シングルスレッドでブロッキングI/Oを使用することで、ワーカーは接続を維持しながら他のクライアントにサービスを提供することはできません。したがって、ユニコンは永続的な接続を実装しません。

アプリケーションの応答がソケットバッファより大きい場合、または大きな要求（アップロード）を処理している場合は、クライアント接続の速度によってワーカープロセスにボトルネックが発生します。ユニコーンがローカルネットワークの外部のクライアントにサービスすることを許可しないでください。