django - Django ドキュメントが静的ファイル用に別のサーバーを提案しているのはなぜですか?

Question

mod_wsgi ページの Django から:

メディアを提供するために、別の Web サーバー (つまり、Django を実行していないサーバー) を使用することをお勧めします。

なんで？

Answer 1

一般に、静的コンテンツ (画像、CSS、JS ファイルなど) を別のサーバーに配置し、さらに別のドメイン/サブドメインに配置することをお勧めします。これにより、静的ファイルを提供するソフトウェアを高度に最適化し、驚くほど高速にすることができます (たとえば、nginx )。

もう 1 つの主なメリットは、ネットワーク トラフィックの減少です。動的 Django アプリと同じドメインから静的コンテンツを提供する場合、クライアント ブラウザーは、静的ファイルであっても、HTTP 要求の一部としてドメインの Cookie を送信します。これは不要なオーバーヘッドです。静的ファイルは常に静的になりますが、クライアントは静的コンテンツと動的コンテンツの違いを認識できないため、必要になります。一方、静的コンテンツが別のドメインから提供されていた場合は、「Cookie のないドメイン」として構成できるため、リクエストのオーバーヘッドが最小限に抑えられます。

Answer 2

これは、Web フレームワーク間で共通の戦略です。ここでの考え方は、静的コンテンツを提供するジョブに最適なツールを単純に使用することです。Apache、Nginx、lighttpd、およびその他の最新の Web サーバーはすべて、静的コンテンツの提供に非常に優れているため、これらのサーバーを簡単に構成してそのジョブを実行できれば、いくつかの利点があります。

1. それらの要求は非常に高速です。
2. 平凡なタスクを実行する重い Python プロセスを占有していないため、アプリケーション リクエストを自由に処理できます。
3. 将来的には、静的コンテンツを処理するためのこの個別のプロセスを持つことで、CDN の使用や他のサーバーへのアセットの分散に関する柔軟性が向上します。

メディアを特定のディレクトリに移動することで、このタスクのために Web サーバーを簡単に構成できます。

Answer 3

セキュリティにも優れています。非常にカットアンドドライなアプローチは、ユーザーがアップロードしたファイルをコア サーバー ファイルから遠ざけることです。フォルダーのアクセス許可などを個別に設定します。しかし、そうです、速度が大幅に向上します。

Answer 4

最新の Web ブラウザーは、1 つのホストからアセットをダウンロードするときに、2 つの (複数の?) ソケットを開くことがよくあります。したがってindex.html、一連の画像、js ファイル、css などを参照するものを取得します。追加の各ファイルは、単一のブロッキング ソケットによってダウンロードされます。

別のホストから静的ファイルを取得すると、ファイルをダウンロードするために 2 つのソケットが余分に使用されるため、本番環境ではこれがはるかに高速に動作します。

nginxこの並列化により、生のコンテンツや動的コンテンツなどfastcgi、提供するものに特化した異なるサーバーエンジンを実行することもできます (同じボックス上にある可能性がありますが、それでもソケットは 2 つしかありません) 。django

Answer 5

ここでの答えはすべて、技術的、理論的な観点からは確かに正しいです。ただし、実際には、Django の展開の大部分では、メディアと Django アプリに別のサーバー (つまり、仮想マシンまたは物理マシン) を使用することは考えもしません。それは必要ありません。そして、それは時期尚早の最適化であり、「諸悪の根源」です。

代わりに、一般的な httpd サーバー (Apache、nginx など) を使用して展開し、WSGI/FastCGIを介してアプリを実行させ、静的ファイルとメディア ファイルも提供させます。これはうまくいきます。特にユーザー メディア用に別のサーバーを使用することを検討している場合は、多くの問題を回避できます。

あなたのサイトがパフォーマンスの問題を抱えているほど成功している場合は、喜んで修正します。そして、あなたの最初のステップは、より高速なサーバーをレンタルすることかもしれません.

これは、少なくともあなたの唯一の懸念がパフォーマンス関連である場合に当てはまります。セキュリティ上の理由から、顧客が要求した場合でも、別のサーバーを使用する必要がある場合があります。