web-dev-qa-db-ja.com

Socket.IOサーバーのパフォーマンスと帯域幅の使用

ローカルコンピューターで小さなソケットサーバーをホストしようとしていますが、使用する帯域幅の種類を知りたいのですが。ほとんどの日では、一度に接続されるクライアントは50以下ですが、週に1〜2回、一度に5,000以上のクライアントを持つことができます。ただし、送信されるメッセージは、接続されているすべてのクライアントに一度に送信される唯一のメッセージであり、追加のデータなどは一切ありません。

サーバーは、ホストされているコンピューターのパフォーマンスを大幅に低下させたり、インターネット速度を低下させたりしますか？

Server.js：

var app = require('http').createServer(handler)
   , io = require('socket.io').listen(app)
   , fs = require('fs')

 app.listen(8001);

function handler (req, res) {
fs.readFile(__dirname + '/index.html',
  function (err, data) {
    if (err) {
      res.writeHead(500);
      return res.end('Error loading index.html');
    }

    res.writeHead(200);
    res.end(data);
  });
}

io.sockets.on('connection', function (socket) {
  socket.on('SendDefault', function(data) {
    socket.broadcast.emit('GetDefault');
  });
});

Client.js：

setTimeout( function( ){ 
  socket = io.connect('[IP Address]:8001');
  socket.on('GetDefault', function(data) {
    DoStuff( );
  );
} ); }, 10000 );
javascriptnode.jsperformancesocket.iobandwidth
24
Joe Boris

帯域幅の量は、サーバーから送信するデータの量、およびクライアントが送信するデータの量に大きく依存します。帯域幅の使用量は、使用しているSocket.IOトランスポート、およびアプリケーションのハートビート間隔にも依存します。

アプリケーションのパフォーマンスへの影響は、実行しているアプリケーションのタイプや、マシンやネットワークのパフォーマンス能力によっても異なります。ただし、アプリケーションを複数のコアにスケーリングしない限り、コンピューターの機能に関係なく、5000以上のクライアントはパフォーマンスに大きな影響を与えます。

プロキシを使用していくつかの測定を行いました。結果は次のとおりです。

クライアントからの放出：socket.emit(event, args)

  • eventおよびargsが指定されていない場合、12バイトがサーバーに送信されます。
  • argsが省略されているがeventが指定されている場合、合計サイズは22バイト、eventの長さになります。
  • argsとeventが指定されている場合、同じ規則に従いますが、結果はargsのデータ型によって異なる場合があります。

サーバーからの送信：クライアントからのフォーマットと同じ

  • eventおよびargsが指定されていない場合、8バイトがクライアントに送信されます。
  • argsが省略されているがeventが指定されている場合、合計サイズは17バイトでeventの長さです。
  • argsとeventが指定されている場合、同じ規則に従いますが、結果はargsのデータ型によって異なる場合があります。

サーバーからクライアントへのハートビート：クライアントごとに25秒ごと

  • サーバーから5バイト
  • 9バイトのクライアント応答

ハンドシェイク：クライアントごとに1回

  • サーバーから216バイト
  • クライアントからの431バイトの応答
  • サーバーから129バイトのフォローアップ

したがって、5000以上のクライアントの負荷では、ハンドシェイクに少なくとも3.7MB、ハートビートに3KB/s、およびsocket.emit()に少なくとも107KBの帯域幅が必要です。クライアントはデータを失ったり、接続を切断したり、再接続する必要がある場合があるため、これらは正確な数値ではありません。

結論として、ネットワークはおそらく停滞しますが、主な関心事は、ネットワークが処理する必要がある同時接続の量です。多くの同時接続もCPUを集中的に使用する可能性があるため、コア間でのクラスタリングについて検討する必要があります。また、Socket.IOサーバーが処理する必要のあるハートビートの量にも注意してください。 50人の同時ユーザーの場合、これは1秒あたり平均2ハートビートです。 5000以上の同時ユーザーでは、1秒あたり200以上のハートビートです。これは、ネットワーク負荷（2.8KB /秒）よりもCPU負荷が高いと思います。

60
hexacyanide

WebSocketは非常に長い時間開いたままにできるため、通常、多数の同時接続を処理することは、増加した負荷に対応するためにそのサービスをスケールアウトする必要があることを意味します。これはほとんどすべてのテクノロジーで同じですが、通常、サーバーがダウンヒルになる前にサーバーが処理できるオープン接続の最大数には制限があります。トラフィックがこのようにピークになる可能性がある場合は、 pusher または kaazing などのサードパーティサービスを検討することを検討します（免責事項：まだ試していません） 。）

かなり漠然とした質問を投稿しましたが（アプリケーション、アーキテクチャなどについては何も知りません-予想されるトラフィックだけです）、それが正しい方向に向くのに役立ちます。言われていること...あなたのユースケースに基づいて（時々1つまたは2つの小さなメッセージをブロードキャストする）、私の直感は、WebSocketはあなたにとって適切なテクノロジーではないと私に言っています。

（帯域幅はおそらく問題ではないことに注意してください-一般的に言えば、WebSocketを介して多くのメッセージを送信する場合と比較してRESTヘッダー、Cookieなどにより、送信するデータが少なくなります。 ）

1
Jesse Fulton