javascript - rooms - El rendimiento del servidor Socket.IO y el uso de ancho de banda

socket.io express

Question

Estoy a punto de alojar un pequeño servidor de socket en una computadora local y me gustaría saber qué tipo de ancho de banda va a usar. La mayoría de los días no tendrá más de 50 clientes conectados a la vez, pero una o dos veces por semana podría tener hasta 5,000 o más clientes a la vez. Sin embargo, los únicos mensajes que se envíen serán mensajes individuales ocasionales a todos los clientes conectados a la vez, sin datos adicionales ni nada.

¿Causará el servidor una disminución significativa del rendimiento en la computadora en la que está alojado o disminuirá mi velocidad de Internet?

Servidor.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 );

Answer 1

La cantidad de ancho de banda dependerá en gran medida de la cantidad de datos que vaya a enviar desde el servidor y de la cantidad de datos que enviará el cliente. El uso del ancho de banda también dependerá de qué transporte Socket.IO esté utilizando y el intervalo de latido de su aplicación.

El impacto en el rendimiento de la aplicación también varía según el tipo de aplicación que esté ejecutando y la capacidad de rendimiento de su máquina y / o red. Sin embargo, más de 5000 clientes tendrán un impacto considerable en el rendimiento, independientemente de las capacidades de su computadora, a menos que esté escalando la aplicación en múltiples núcleos.

He tomado algunas medidas utilizando un proxy. Aquí están los resultados:

Emisión desde un cliente : socket.emit(event, args)

• Si no se suministran event y args , se envían 12 bytes al servidor.
• Si se omite args pero se proporciona el event , el tamaño total es de 22 bytes y la duración del event .
• Si se proporcionan args y event siguen las mismas reglas, pero los resultados pueden variar según el tipo de datos de args .

Emisión desde el servidor : mismo formato que desde el cliente

• Si no se suministran event y args , se envían 8 bytes al cliente.
• Si se omite args pero se proporciona el event , el tamaño total es de 17 bytes y la duración del event .
• Si se proporcionan args y event siguen las mismas reglas, pero los resultados pueden variar según el tipo de datos de args .

Latido del servidor al cliente : cada 25 segundos por cliente

• 5 bytes del servidor
• Respuesta de cliente de 9 bytes.

Apretón de manos : una vez por cliente.

• 216 bytes del servidor
• Respuesta de 431 bytes del cliente.
• 129 bytes de seguimiento desde el servidor

Por lo tanto, con una carga de más de 5000 clientes, espere al menos 3.7MB para el protocolo de enlace, 3KB / s para latidos y al menos 107KB de ancho de banda para un socket.emit() . Estas no son cifras exactas, ya que los clientes pueden perder datos, desconectar conexiones, necesitan volver a conectarse, etc.

En conclusión, su red probablemente se mantendrá, pero la principal preocupación debe ser la cantidad de conexiones simultáneas que su red deberá manejar. Muchas conexiones simultáneas también pueden consumir mucha CPU, por lo que debe pensar en agrupar en clústeres a través de núcleos. También tenga en cuenta la cantidad de latidos que el servidor Socket.IO tendrá que manejar. Con 50 usuarios concurrentes, eso es un promedio de 2 latidos por segundo. Con más de 5000 usuarios concurrentes, eso es más de 200 latidos por segundo, lo que me imagino que requiere más CPU que intensivo en red (2.8KB / s).

Answer 2

WebSockets puede permanecer abierto durante mucho tiempo, por lo que el manejo de una gran cantidad de conexiones concurrentes generalmente significa que necesitará escalar ese servicio para adaptarse a la mayor carga. Esto es lo mismo para casi cualquier tecnología, pero por lo general hay un límite para el número máximo de conexiones abiertas que un servidor puede manejar antes de que las cosas vayan cuesta abajo rápidamente. Si es probable que tenga tales picos en el tráfico, consideraría buscar un servicio de terceros como kaazing o kaazing (descargo de responsabilidad: tampoco lo he intentado aún).

Ha publicado una pregunta bastante vaga (no sabemos nada acerca de su aplicación, arquitectura, etc., solo el tráfico esperado), pero espero que eso le ayude a apuntar en la dirección correcta. Dicho esto ... basado en su caso de uso (emitiendo uno o dos mensajes pequeños, ocasionalmente), mi instinto me dice que WebSockets no es la tecnología adecuada para usted.

(Tenga en cuenta que el ancho de banda probablemente no debería ser una preocupación, en general, si envía muchos mensajes a través de WebSockets frente a REST, enviará menos datos debido a encabezados, cookies, etc.)