uWSGIがあるときにnginxが必要な理由


62

Djangoアプリケーションをデプロイするときに、nginxをuWGSIと連携するように構成する方法に関するチュートリアルが多数あります。

しかし、なぜこのキットにnginxが必要なのですか?uWSGI自体はWSGI Pythonアプリケーションを提供でき、静的ファイルを提供でき、SSLも実行できます。nginxはuWSGIではできないことを何ができるのでしょうか?


9
この質問は意見に基づいて閉じられていることがわかります。私はまったく同意しません。質問「nginxはuWSGIができないことを何ができるのですか?」事実に基づいています。
user983447

1
私は一般的に再開を話さないが、この場合、私は同意する。既存の支持され受け入れられた答えは良いものです。それは、書かれているように、質問が賢明で関連する答えを認めていることを示しています。それはおそらく良い質問になると思います。
MadHatter

回答:


55

あなたはしません。

とにかくそれは簡単な答えです-あなたはそれを必要としません。uWSGIはそれ自体が有能なサーバーです。

ただし、nginxのような他のサーバーはより長く、(おそらく、とにかく)より安全であり、uWSGIでサポートされていない追加機能(たとえば、ExpiresまたはE-Tagの組み合わせによる静的リソースの処理の改善)サーバーとネットワークの負荷を大幅に削減できるヘッダー、gzip圧縮、事前圧縮されたgzipなど)。さらに、Djangoアプリケーションの前にあるnginxなどのサーバーは、動的コンテンツのキャッシングも実装できます。これにより、サーバーの負荷をさらに軽減し、CDNの使用を促進することもできます(通常、動的コンテンツではうまくいきません) )。さらに進んで、nginxを完全に別のサーバーに配置し、静的コンテンツ自体を処理しながら、負荷分散されたアプリケーションサーバーのクラスターに動的コンテンツの要求をリバースプロキシすることもできます。

たとえば、私のブログ(WordPressの前にnginxがあります)は、投稿を24時間キャッシュし、インデックスページを5分間キャッシュするように調整されています。ほとんどの時間を本当に必要とするほどトラフィックが足りない間、それは私の小さなVPSが時折急増するのを防ぐのに役立ちます-記事の1つが選ばれたときのトラフィックの急増など数千人のフォロワーがいるツイッターがアップし、その多くが数千人のフォロワーにそれをリツイートしました。

「裸の」uWSGIサーバーを実行していた場合(そして、WordPressではなくDjangoサイトであったと仮定すると)、それはうまく立ち上がったかもしれません-クラッシュして燃えたかもしれません。 。その負荷を処理するためにnginxをその前に置くと、本当に役立ちます。

そうは言っても、多くのトラフィックが表示されない小さなサイトを実行している場合は、nginxやその他のものは実際に必要ありません。一方、大量のトラフィックが表示される場合は...まあ、まだ uWSGIが必要かもしれませんが、少なくともその前に何かを考えて負荷を軽減する必要があります。実際、完成したサイトでさまざまな構成の負荷テストを実際に行い、予想される負荷の下で最適なものを判断し、最終的には何でも使用する必要があります。


3
@Kromeyが彼らの答えでカバーしたものに加えて、私が思うに思い浮かぶ1つのことは、uWSGIのネイティブプロトコルがhttpではなく、uwsgiプロトコルであるということです。uwsgiプロトコルはhttpよりも簡単で効率的に処理できるため、uWSGIアプリケーションの前にフル機能のWebサーバー(nginxまたはwhatnot)を貼り付けることで、実際に多くの処理が重複することはなく、ニーズ。
-HåkanLindqvist 14

@HåkanLindqvistは絶対に正しいです。明確にするために、uWSGIはHTTPを完全に「話す」ことができるため、それだけで十分に立つことができますが、その前のWebサーバーがHTTPではなくuwsgiプロトコルを使用することに注意する価値がありますuWSGIに話しかけるため、処理の重複はほとんどありません。
クローミー14

これは罰金答えは、しかし、それはあなたが何より具体的に説明して話題にuWSGI自身のドキュメントへのリンクを改善することができたことができます:uWSGIをどうuwsgi-docs.readthedocs.io/en/latest/...
トビアスマクナルティ

1

IMO、あなたのウェブサイトをラボではなくインターネットに置くと、違いが見えるかもしれません。

ネットワーク速度が遅い他の国のユーザーがWebブラウザーを開いてWebサイトにアクセスすることを想像してください。uWSGIは、そのHttp接続をスレッドで処理します。そのスレッドは、ネットワーク速度が遅いため、完全なHttp要求を待機するのにかなり長い時間を費やす可能性があります。スレッドプールのサイズが100の場合、100人のユーザーがそのように遅いと想像してください。どうなりますか?他のHttp要求を処理するアイドルスレッドはありません。

しかし、Nginxの場合はまったく異なります。Nginxは「Reactor Pattern」で設計されています。「Reactor Pattern」をグーグルで検索して、動作を確認できます。要するに、低速接続は、他のHttp要求を処理するのに影響しません。


1
Nginxを使用することでそれが変わるとは思えません。DjangoアプリケーションがWSGIを使用してApacheでホストされている場合、POSTデータがソケットから読み取られる前に、view関数が呼び出されます。そのため、クライアントが遅い場合、POSTデータが受信されるまで、リクエストを受信したスレッドを占有します。ApacheをNginxに置き換えるとなぜ変更されるのですか?
カスペルド

1
私が知っているように、デフォルトでは、Nginxは完全なHTTPリクエストを取得するまでHTTPリクエストをバックエンドアプリケーションサーバーにプロキシしません。したがって、Djangoのようなアプリケーションサーバーの場合、取得されるのは常に高速HTTP接続とリクエストであり、完全なhttpリクエストを待つ時間を無駄にしません。クエストをすぐに処理した後、実行中のスレッドはすぐに次のHttpリクエストに対してアイドル状態になります。
Jcyrss

1
これは、nginxのではデフォルトで有効になっていますリクエストのバッファリング、(nginxのの古いバージョンでは、これをオフにすることはできませんでした)と呼ばれている:nginx.org/en/docs/http/...
トビアスマクナルティ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.