Socket.io: Recuento de clientes / sockets conectados

+1. Creo que en mi caso, este es un último problema que causa problemas de memoria (creciendo hasta una falla de segmentación).

Sí, se bloquea aproximadamente dos veces al día con una falla de segmentación aquí.

se indica en la "documentación":
http://labs.learnboost.com/socket.io/

en la sección Servidor / Oyente Socket.IO Node.JS (haga una búsqueda en la página de "empalme"). Citar:

"Una matriz de clientes. Importante: los clientes desconectados se establecen en nulo, la matriz no está empalmada".

Pasar del pensamiento al código y a la documentación significa que tiene que haber alguna razón por la que los usuarios desconectados no se eliminen de esta matriz, simplemente no puedo adivinar cuál es esa razón. El mejor de los casos es que hace que el seguimiento de los usuarios CONECTADOS sea un problema y, en el peor de los casos, está contribuyendo a la falta de estabilidad en una implementación de servidor node.js / socket.io.

Marcado como error de rendimiento.

Tengo el mismo problema.

y hago mi base numérica en alguna var con i +1 durante el evento de conexión y -1 durante la desconexión. (entonces este no es un problema nulo)

Cuenta de usuario:

https://skitch.com/tomekotomek/f4867/dock

UPC:

https://skitch.com/tomekotomek/f489w/dock

MEMORIA:

https://skitch.com/tomekotomek/f4eyy/graph.php-747x374

Por cierto.

es más que un problema de rendimiento, simplemente reduce nuestro tiempo de actividad a menos de una semana.

La forma en que descubrí cómo hacer esto fue usar un conjunto de Redis de los identificadores de cliente, agregar el socket.io connect y eliminar del conjunto al desconectar. El comando SCARD le proporciona el número de clientes conectados y SMEMBERS todos los identificadores.

Sí, la matriz debe limpiarse o se debe encontrar una mejor manera de mantener a los clientes.

+1

+1

+1
Definitivamente, esto es más que un problema de longitud de matriz.
Incrementar y decrementar un contador al conectar / desconectar resultará en un contador cada vez mayor.

+1

+1

+1

+1

+1

¿Alguien ha intentado aislar esto a los distintos transportes? Es decir, mira si funciona igual en
websocket, flashsocket, xhr-polling, etc.

Este es definitivamente un tema importante, ya que no podemos dejar el servidor funcionando de manera constante sin reiniciar. Ni siquiera puedo pasar un día sin al menos un reinicio, ya que la memoria sigue creciendo. NOTA: En el nodo 0.4. * La memoria es MUCHO MEJOR para mí.

+1

Descubrí el mismo problema: mi memoria se llena. alrededor de 1 mb / por minuto

con aproximadamente 1500 enchufes que se vuelven a conectar debido a los clics en el sitio havy.

debe reiniciarse diariamente debido a la pérdida de memoria

L2C FAF IT RTFM !!!
° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° °
° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° °
° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° °
° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° °
°
° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° °
█ ° █ ° █ ° ° ° ° ° ° █ ° ° ° ° ° ° ° ° ° █ °
█
° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° °
Moision
Moision
° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° °
° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° °
° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° °
° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° °
° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° °

Acabo de apagar el lado del servidor de transporte flashsocket y el uso de la memoria Y el uso de la CPU es MUCHO MEJOR. ¿Alguien más puede probar eso y ver si eso ayuda?

+1

Lo retiro, la CPU ES MEJOR pero la memoria aún se filtra lentamente. Supongo que esto se debe a que el servidor de políticas flash se apaga.

Deje de inflar el feed con "+1", esto no es ni de google plus ni de facebook ...

hombre, tengo que hacerlo +1 a eso

También hay una Desactivación de notificaciones para este problema a continuación.

En mi caso, socket.manager.closed, socket.manager.handshaken es más que socket.manager.open. y no se borrar las conexiones inútiles

EXACTAMENTE lo mismo aquí. Tenemos que reiniciar el servidor tantas veces al día, porque las conexiones consumen cada vez más memoria hasta que nos quedamos sin 4GB de memoria.
Estaré muy feliz si este problema se resuelve, porque no puedo seguir usando socket.io si tengo que reiniciar cada pocas horas. (Tenemos alrededor de 2000 usuarios en línea al mismo tiempo, conectándose y desconectando)

Estoy usando socket.io 0.9.10 y el siguiente código para determinar el número de sockets:

var socketIO = require ('socket.io'). listen (.....
...
var numberOfSockets = Object.keys (socketIO.connected) .length;

No estoy seguro de cuán exacto reacciona este número a los diversos casos extremos, pero hasta ahora parece exacto: cada navegador que se conecta aumenta el número, cada navegador que se cierra lo disminuye.

¿Hay algún problema con este enfoque?

Dejando de lado los problemas de conteo (que se pueden solucionar), los problemas de memoria son bastante brutales aquí. ¿Hay alguna esperanza de que esto se solucione en el futuro? Significa que las implementaciones de socket.io de larga duración y alta actividad son muy difíciles de administrar.

Alternativamente, ¿alguien sabe acerca de las bifurcaciones que tienen este problema solucionado?

El problema está relacionado con el siguiente código (tomado de socket.io 0.9.10):

  SocketNamespace.prototype.clients = function (room) {
    var room = this.name + (room !== undefined ? '/' + room : '');

     if (!this.manager.rooms[room]) {
         return [];
     }

     return this.manager.rooms[room].map(function (id) {
         return this.socket(id);
     }, this);
  };

el método this.socket(id) crea una nueva instancia de socket, por lo que usar eso en cada conexión de socket produciría una pérdida de memoria.

@dknaus proporcionó una excelente solución para eso;)

@outbounder ¿Puede señalar cuál fue en realidad esa excelente solución? Porque todo lo que veo en este hilo es un recuento de sockets activos

@marksyzm

 Object.keys(socketIO.connected).length;

esto es válido solo si tiene una tienda adjunta a socketio. de lo contrario, la única forma de evitarlos es contarlos por lógica personalizada así:

 io.on("connection", function(s){ 
   connectedCount += 1; 
   s.on("disconnect", function(){
     connectedCount -= 1;
   });
 });

@outbounder pero pensé que el objetivo de este error es solucionar el problema de pérdida de memoria con los sockets que no se desconectan. ¿Me estoy perdiendo de algo?

la memoria se está desangrando de algún lugar ver

https://github.com/LearnBoost/socket.io/issues/1015

https://github.com/sockjs/sockjs-node/issues/81

https://github.com/joyent/node/issues/2328#issuecomment -3190337

No estoy seguro de si su websocket está relacionado o relacionado con el nodo o ambos

sockjs tiene problemas similares, lo que significa que podría ser que socket.io y sockjs usen el mismo ws lib, que tiene un problema con el nodo, o es solo un problema general del nodo

+1

Esto todavía me está pasando en producción. En realidad, ni siquiera tengo tantos clientes conectados: 100-200 en el pico. Los procesos simplemente se están quedando sin memoria y se cuelgan o mueren. ¿Alguien está trabajando en esta pérdida de memoria? ¿Cómo puedo ayudar?

Por lo que puedo decir, este ha sido un problema conocido durante años y todos los que aspiran a implementaciones reales se han mudado de socket.io. No ha habido ningún movimiento sobre este problema, y ​​engine.io no parece interferir con los núcleos de transporte en absoluto, por lo que tampoco hay razón para esperar que eso solucione esto.

Honestamente, he estado buscando evidencia de que CUALQUIERA implemente vanilla socket.io en producción con un transporte websocket activo y no he encontrado ningún informe confiable. Trello es un usuario de alto perfil, pero admitió haber usado algún tipo de versión parcheada que no se lanzó y solo usa el transporte websocket (en ese momento, ¿por qué usar socket.io en absoluto?). Me mudé de socket.io por completo porque no parece que esto vaya a cambiar pronto. No puedo prometer que sockjs no tenga problemas, pero estoy seguro de que no falla tan rápido como lo hace socket.io si te unes / dejas a unos pocos miles de clientes.

Estaba luchando con lo que creo que es este problema, en mi propia aplicación socket.io/redis, en Nodejitsu. Definitivamente parece que es la tienda Redis de socket.io. Voy a cambiarme a SockJS y escribir mi propia gestión de Redis, creo.

Registros de chat de mí trabajando a través de él en el canal de soporte #nodejitsu:
https://gist.github.com/4146668

+1

¿Soy yo, o socket.io ya no usa redis?

¿Qué tal agregar this.store.publish ('desconectar', id); a Manager.prototype.onClientDisconnect
como se sugiere aquí: https://github.com/LearnBoost/socket.io/issues/831

¿Habrá algún problema al agregar esta línea? Me gusta saber.

¿Segundo eso?

+1

+1

¿Nadie?

¿Algún movimiento sobre este tema? Espero implementar en un futuro cercano y realmente valoraría cualquier conocimiento que tengan las personas con implementaciones de producción sobre este tema.

El arreglo anterior funcionó para nosotros ... la carga se redujo significativamente
El 4 de junio de 2013 a las 11:01 a.m., "patrickod" [email protected] escribió:

¿Algún movimiento sobre este tema? Espero implementar en un futuro cercano y
realmente valoraría cualquier conocimiento que las personas con implementaciones de producción tengan
en este tema.

-
Responda a este correo electrónico directamente o véalo en Gi
.

¿Deshabilita la compatibilidad con zócalo flash? La documentación dice que esto ahora se hace de forma predeterminada.

Nunca me he enfrentado a este problema, pero todavía estoy en desarrollo y evaluación comparativa. ¿Esto ha sido resuelto?

Tú dinos. Estás haciendo pruebas comparativas. :RE

El jueves 23 de enero de 2014 a las 7:07 a.m., Maziyar Panahi [email protected] escribió:

Nunca me he enfrentado a este problema, pero todavía estoy en desarrollo y evaluación comparativa.
¿Esto ha sido resuelto?

-
Responda a este correo electrónico directamente o véalo en Gi
.

Tú dinos. Estás haciendo pruebas comparativas. :RE

Honestamente, no he notado una caída en grandes cantidades. He visto pocas conexiones caer después de 5 6 minutos cuando conecto 1000 usuarios al mismo tiempo, pero se vuelven a conectar muy rápido y tengo más de 10K mensajes por segundo para todos los usuarios. Así que creo que mi instancia EC2 (m1.large) simplemente no es lo suficientemente fuerte como para mantenerlos a todos vivos sin dejar caer algunos.
Me preguntaba si enfrentaré este problema en el futuro. El mío es dejar caer unos pocos y volver a conectarlos en la prueba de esfuerzo. Después de desconectar todo, puedo ver que el número de clientes cae a 0.

+1

No he tenido problemas con todo esto desde 10.11 ... ¿Podría atribuirlo al uso de ubuntu 10.10? De cualquier manera, parece estar bien ahora.