http応答ブロックnodejsをストリーミングしていますか？

Question

私は負荷の下でたくさんのコンテンツをディッシングするときにnodejの限界を理解しようとしています。具体的には、クライアントへの長い応答をストリーミングすることがブロックされるかどうかを知りたい。

私は非常に単純なテストセットアップを作成しました。ここでは、ノードがすべてのリクエストに対して、1GBのHTTPダウンロードから取得したストリームで応答します。私のコードは次のとおりです。

var http = require('http'); 
var fs = require('fs'); 

var iterator = 0; 

http.createServer(function(req, res) { 

    console.log('req received ', iterator++); 

    var url = 'http://download.thinkbroadband.com/1GB.zip'; 

    http.get(url, bigFile => { 

     res.writeHead(200, { 
      'content-type': 'application/zip', 
      'content-length': bigFile.headers['content-length'], 
     }); 

     bigFile.pipe(res); 

    }); 

}).listen(8003); 

私はこのノードサーバーを起動し、ブラウザのいくつかのタブでエンドポイントを押しました。興味深いのは、後の応答がただちにconsole.log('request received ', iterator++);コードで記録されないということでした。代わりに、初期イベントが記録されるまでに5〜10秒の遅延があります。

http応答のストリーミングがブロックされている場合、最初のリクエストが完了するまで待機してから2番目のリクエストを受け入れる必要があるため、これは私にとっては奇妙です。もしストリーミングがブロックされなければ、リクエストされた直後にすべてのリクエストが記録されることが期待されます。

誰かがこれを説明できますか？

ここでもパフォーマンスについてのご意見をお待ちしております。ノードはおそらくこの種のもののために作られたものではないでしょう。ダウンロード速度は、複数の要求で本当に苦しんでいます。

Answer 1

もう少し研究を重ねると、イベントループのさまざまなフェーズが、私が見ている結果をどのように引き起こすかを確認できます。ノードguidesは、すべてのI/Oイベントを実行するポーリングフェーズが必要に応じてブロックされる方法と、最大スタックを持ち、メインスレッドを長時間にわたって完全にブロックしない方法について説明します。

これは、たくさんのI/Oイベントがある場所（たとえ私がディレクトリon('data')...でディレクトリを聞いていなくても）がノードアプリケーションを一時的にブロックする可能性があることを説明します。私は最初の要求の後に約5〜10秒遅れて、何かが逃げることができないのを見ました。

もちろん、クラスターモジュールを使用してマシン上で使用可能なすべてのプロセッサーを使用するなど、パフォーマンスを向上させるために行うこともできます。しかし、今日の終わりにノードがおそらく最善の解決策ではないでしょう。あなたは、必要なすべてのスレッドを備えた従来のWebサーバーよりもはるかに優れたパフォーマンスを得ることができます。すべてのプロセッサを使用した後でも、ノードを使用してCPU使用率を約6％しか押していませんでした。