15

この問題は特に Nodejitsu に関連していますが、同様の影響が他の VPS でも発生しているようです。私は socket.io を使用したリアルタイム ゲームを持っています。私が気づいたことの 1 つは、サーバーが応答するまでに非常に長い時間待機することがあるということです。その時間枠内に複数のリクエストが送信された場合、それらはすべてキューに入れられて一度に処理されたかのように動作します。共有ハードウェア上の他のユーザーの存在と漠然と相関していると思われます (VPS の場合と同様)。

とにかく、これをテストする (そして、それが私のゲームのコードによるものではないことを確認する) ために、最小限のテスト ケースを作成しました。

express = require('express')
http = require('http')

app = express()
server = http.Server(app)

io = require('socket.io').listen(server)

io.sockets.on('connection', function(sock){
    sock.on('perf', function(data, cb){
        cb([Date.now()]); //respond with the current time
    })
})

app.get('/', function(req, res){
    res.header("Access-Control-Allow-Origin", "*")
    res.header("Access-Control-Allow-Methods", "HEAD,GET,PUT,POST,DELETE")
    res.header("Access-Control-Allow-Headers", "X-Requested-With")

    res.end(JSON.stringify([Date.now().toString()])); //http equivalent of perf function
})

server.listen(process.env.PORT || 6655, function(){
    console.log('listening now')
})

perf定期的にイベントを送信し、コールバックが起動するのにかかった時間を示す socket.io を含む単純な空白の HTML ページがありました。そして、それはまだ同じことを示しています:

ラグスパイクを示すグラフ

バーの長さは、線形量ではなく、時間の平方根を表すことに注意してください。

socket.io に依存する代わりに、XHR を使用して現在の応答時間の同様の測定を行ったところ、結果は非常に似ており、多くの低遅延応答 (ただし、予想どおり Websocket よりも高いベースライン) といくつかの時折の応答が得られました。積み重なって見えるスパイク。

奇妙なことは、複数のブラウザ ウィンドウと異なるブラウザで開くと、異なるブラウザ間に相関があるように見えることです (そして、一部のサーバーではまったく存在しないか、大幅に頻度が低いという事実)。サーバー側の現象。ただし、一部のブラウザでは発生するが他のブラウザでは発生しないレイテンシ スパイクがあり、同じセッションの 2 つの Chrome ウィンドウは実質的に正確に重複しているように見えます。賢い）。

左から右へ: Chrome シークレット、Chrome (通常)、Firefox、Chrome (通常)

4 つのウィンドウのグラフ

とにかく、これは何ヶ月も私を混乱させてきました.何が原因で、どのように修正するのかを本当に理解したい.

4

3 に答える 3

2

CPUまたはRAMに問題があるかどうかを確認したと思います。

「驚くべき」方法でノードを遅くすることができる唯一のものは、ガベージ コレクター--trace*です。( を参照してくださいnode --v8-options。)

個人的には、そこから何もわからないと思います。なぜなら、それは私の感覚にすぎませんが、問題は別の場所にあるからです。

500 ミリ秒の乗算の完全な遅延により、パケット損失が発生したと想定します。ifconfigそれが一般的な問題であるかどうかを確認してからtcpdump、パケットを再送信するかどうかを確認できます。

于 2013-06-29T06:41:15.953 に答える
0

これが表示される理由は、Nagle のアルゴリズムによるものです。これは、I/O で使用されるアルゴリズムであり、データをしばらくバッファリングしてから、より大きなデータのチャンクを送信します。送信を（ソケットで）保存するために使用されます。詳細については、 http://en.wikipedia.org/wiki/Nagle's_algorithmをご覧ください。

Nagle のアルゴリズムを無効にするには (多くの小さなリクエストをできるだけ早く送信したい場合に適しています)、socket.setNoDelay(true); を実行します。net.Socket() を使用している場合。socket.io の場合、Nagle は Websocket ではデフォルトで無効になっていると思いますが、他のプロトコルでは必ずしも無効になっているとは限りません。node.js から net.Sockets を使用してテストを実行し、Nagle を無効にして、何が得られるかを確認することをお勧めします。

于 2013-06-29T15:47:37.797 に答える
0

これは奇妙に聞こえるかもしれませんが、これはノードの問題ではなく、OS の設定の問題だと考えていますか。ファイル ハンドルと、OS がソケットに表示している接続数を確認しましたか? また、OS のソケット タイムアウトが十分に低いことを確認しましたか? 他のコードでも同様のパフォーマンスの問題に遭遇しましたが、それはコードではなく OS であることが判明しました。また、パッケージを確認し、ソケットで許可されている接続を開くために何が含まれているかを確認してください。ノード コードは確認していませんが、Java の http クライアント ライブラリで同様の問題が発生しました。アプリケーションはバックアップしたばかりで、接続数の構成の問題にすぎませんでした。

于 2013-06-27T14:39:29.090 に答える