Número máximo de conexiones Socket.IO simultáneas


123

Esta pregunta se ha hecho anteriormente, pero no recientemente, y no tiene una respuesta clara.

Con Socket.io, ¿hay un número máximo de conexiones simultáneas que se pueden mantener antes de que necesite agregar otro servidor?

¿Alguien sabe de algún entorno de producción activo que esté usando websockets (particularmente socket.io) a gran escala? Realmente me gustaría saber qué tipo de configuración es mejor para conexiones máximas.

Debido a que los Websockets se construyen sobre TCP, tengo entendido que, a menos que los puertos se compartan entre las conexiones, estará limitado por el límite de puertos de 64K. Pero también he visto informes de conexiones de 512K usando Gretty . Entonces no lo sé.


3
Trello usa sockets a gran escala (específicamente, socket.io).
James

Leí que Trello tuvo que modificar el código Socket.io debido a un límite de conexión de 10,000 y pude mantener 'muchos miles' de conexiones antes de agregar servidores. Sigue siendo un gran abismo entre eso y 512K de otros sistemas de servidor.
Andrew

1
¿Qué edad tiene ese artículo? Trello ha alcanzado recientemente más de 1 millón de usuarios activos por mes, así que me imagino que ahora están ejecutando más de 10,000 sockets activos. Trello usa Redis para sentarse encima de socket.io para la escalabilidad
James

2
Trello ahora aparentemente tiene más de 4 millones de usuarios, pero seguramente lo están ejecutando en una gran cantidad de servidores, ¿verdad? Eso me devuelve a mi pregunta original: ¿cuál es su recuento máximo real de usuarios concurrentes (o el de cualquier otra persona) por servidor? También sería bueno saber qué tipo de servidor / contenedor utilizan. ¿Y siguen ejecutando su propia bifurcación o están de vuelta al origen / maestro? Mi único propósito al hacer esta pregunta era tratar de evaluar si mi empresa (en ese momento) podía permitirse mantener una aplicación Socket.io para probablemente 120.000 conexiones simultáneas.
Andrew

1
Con respecto al límite de puertos, creo que la explicación de por qué eso no es un problema se explica aquí . Básicamente, el único puerto que se usa en su sistema es el que está escuchando. Se crean sockets para cada conexión, y esos usan descriptores de archivo, pero no usan puertos en su caja.
Paul Lynch

Respuestas:


77

Este artículo puede ayudarlo en el camino: http://drewww.github.io/socket.io-benchmarking/

Me hice la misma pregunta, así que terminé escribiendo una pequeña prueba (usando XHR-polling) para ver cuándo las conexiones comenzaron a fallar (o retrasarse). Encontré (en mi caso) que los sockets comenzaron a funcionar alrededor de 1400-1800 conexiones simultáneas.

Esta es una breve descripción que hice, similar a la prueba que usé: https://gist.github.com/jmyrland/5535279


7
Me doy cuenta de que este es un tema más antiguo, pero lo encontré primero cuando buscaba una pregunta para mi respuesta y finalmente descubrí que esto era útil: rtcamp.com/tutorials/linux/increase-open-files-limit El límite de archivos abiertos por proceso puede predeterminado a un límite flexible de 1024 y un límite estricto de 4096 y dado que cada puerto TCP abierto representa un archivo, es importante considerar estos límites al determinar cuántos sockets abiertos permitirá una máquina antes de intentar maximizar la biblioteca.
DeeperID

2
@JAM ¿Alguna vez descubrió por qué sus conexiones web funcionaban alrededor de 1400-1800 conexiones? Tengo el mismo problema y los límites de mi archivo están establecidos en 100.000, así que sé que ese no es el problema. Cualquier ayuda será muy apreciada. Gracias.
Seth

@seth: ha pasado un tiempo desde la última vez que revisé esto, pero creo que esta fue la conclusión: el sondeo XHR consumió demasiados recursos (en relación con otros métodos de transporte). Al usar websockets, la cantidad de conexiones simultáneas fue mayor.
JAM

@JAM gracias por la respuesta. Veo los mismos problemas al usar el módulo ws, no socket.io, por lo que no debería haber ningún sondeo XHR con el módulo ws. Ahí es donde tengo problemas para solucionar problemas. La búsqueda continúa.
Set

Esta es una buena respuesta limpia ... También es correcta, ya que es caso por caso. Personalmente, sugiero que las personas escriban sus propios puntos de referencia o simulador de conexión. Si bien una prueba para otra persona puede ser buena, no representa el entorno del mundo real ... Una vez que tenga un simulador de cliente capaz de manejar cualquier número de clientes con varias fallas del mundo real ... Puede realizar evaluaciones comparativas después de cambios importantes y también actualice su simulador sobre la marcha. Operar una interfaz de chat de usuario sería diferente a monitorear el navegador de los usuarios y así sucesivamente. Python me resultó muy útil para crear un script de un simulador ...
Angry 84

16

Traté de usar socket.io en AWS, como máximo puedo mantener estables alrededor de 600 conexiones.

Y descubrí que es porque socket.io usó el sondeo largo primero y luego actualizó a websocket.

después de configurar la configuración para usar solo websocket, puedo mantener alrededor de 9000 conexiones.

Establezca esta configuración en el lado del cliente:

const socket = require('socket.io-client')
const conn = socket(host, { upgrade: false, transports: ['websocket'] })

2
¿Usó EC2, qué tipo de instancia? t2.micro, t2.nano?
bvdb

2
¿Notó una diferencia en la capacidad de respuesta cuando fuerza los websockets?
Lauren

¿Sabes qué tamaño tenía tu instancia? Además, cualquiera en el futuro sepa que algunos navegadores antiguos no son compatibles con WebSockets, por lo que la actualización puede ser importante para algunos.
Ryan Soderberg

¿Cómo podemos probar la cantidad de conexión que admite el servidor? ¿Cómo mediste las 9000 conexiones? Por favor sugiera ...
Desarrollador curioso


6

Para conexión simultánea de + 300k:

Establezca estas variables en /etc/sysctl.conf:

fs.file-max = 10000000 
fs.nr_open = 10000000

Además, cambie estas variables en /etc/security/limits.conf:

* soft nofile 10000000
* hard nofile 10000000
root soft nofile 10000000
root hard nofile 10000000

Y finalmente, aumente también los búferes de TCP en /etc/sysctl.conf:

net.ipv4.tcp_mem = 786432 1697152 1945728
net.ipv4.tcp_rmem = 4096 4096 16777216
net.ipv4.tcp_wmem = 4096 4096 16777216

para obtener más información, consulte https://www.linangran.com/?p=547


¿Cómo comprobar si nuestros cambios están funcionando?
Desarrollador curioso
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.