静的ファイルを提供するためのnode.js自体またはnginxフロントエンド？
より高速なベンチマークまたは比較はありますか？nginxをノードの前に配置して静的ファイルを直接提供するか、ノードのみを使用して静的ファイルを提供しますか？
nginxソリューションは私にとってより管理しやすいようですが、何か考えはありますか？
ここでの答えに反対する必要があります。 Nodeは正常に動作しますが、nginxは正しく設定すると最も確実に高速になります。nginxは同様のパターン（必要な場合のみ接続に戻る）を小さなメモリフットプリントでCに効率的に実装します。さらに、 sendfile syscallをサポートして、ファイルを提供するのと同じくらい高速なファイルを提供します。これは、OSカーネル自体がジョブを実行しているためです。
現在、nginxはフロントエンドサーバーとして事実上の標準になっています。静的ファイル、gzip、SSL、さらにはロードバランシングを提供する際のパフォーマンスのために使用できます。
追伸：これは、リクエスト時にディスクに保存されているファイルが本当に「静的」であることを前提としています。
クイックab -n 10000 -c 100静的1406バイトを提供する場合favicon.ico、nginx、Express.js（静的ミドルウェア）、およびクラスター化されたExpress.jsの比較。お役に立てれば：
残念ながら、マシン上でnginxがエラーをスローし始めるので、1000または10000の同時リクエストをテストすることはできません。
[〜＃〜] edit [〜＃〜]：artvolkが示唆するように、クラスター+ staticミドルウェア（遅い）の結果は次のとおりです。
@gremoのチャートの解釈は異なります。ノードとnginxの両方が同じリクエスト数（9〜10k）でスケールするように思えます。確かに、nginxの応答の遅延は20ミリ秒ほど短くなりますが、ユーザーが必ずしもその違いを認識するとは思いません（アプリが適切に構築されている場合）。マシンの数が固定されている場合、ノードが最初にほとんどの負荷が発生する場所であることを考慮して、ノードマシンをnginxに変換する前にかなりの負荷がかかります。これに対する1つの反論は、負荷分散のためにすでにマシンをnginx専用にしている場合です。その場合は、静的コンテンツも同様に提供することができます。
どちらにしても、静的ファイルをキャッシュするようにNginxをセットアップします ...そこに大きな違いが見られます。次に、ノードからサービスを提供するかどうかにかかわらず、基本的にノードアプリで同じパフォーマンスと同じ負荷軽減を実現しています。
私は個人的に、ほとんどの場合、静的アセットを提供するNginxフロントエンドのアイデアが好きではありません。
1）プロジェクトは同じマシン上にある必要があります-またはアセット（nginxマシン上）とWebアプリ（スケーリングのために複数のマシン上）に分割する必要があります
2）Nginxの設定は、静的アセットのパスの場所を維持する必要があります/変更時にリロードします。
それは答えるのが難しい質問です。静的ファイルを提供するだけの非常に軽量なノードサーバーを作成した場合、nginxよりもパフォーマンスが向上する可能性が高くなりますが、それほど単純ではありません。 （ 「ベンチマーク」 nodejsファイルサーバーとlighttpdの比較-静的ファイルを提供する場合のパフォーマンスはngingxと同様です）。
静的ファイルの提供に関するパフォーマンスは、多くの場合、Webサーバーが作業を行う以上のものになります。可能な限り最高のパフォーマンスが必要な場合は、CDNを使用してファイルを提供し、エンドユーザーの待ち時間を短縮し、エッジキャッシュの利点を活用します。
あなたがそれを心配しないなら、ノードはほとんどの状況で静的ファイルをうまく提供できます。 Nodeは非同期コードに役立ちます。これはシングルスレッドであり、すべてのブロッキングI/Oがプロセス全体をブロックし、アプリケーションのパフォーマンスを低下させる可能性があります。コードをノンブロッキング方式で記述しますが、同期的に何かを行うと、ブロッキングが発生する可能性があり、他のクライアントが静的ファイルを提供する速度を低下させる可能性があります。可能性がないか、常に強制できるとは限りません。