Socket.io: Nombre de clients / sockets connectés

+1. Je pense que dans mon cas, c'est un dernier problème causant des problèmes de mémoire (croissant jusqu'à défaut de segmentation).

Oui, se bloque environ deux fois par jour avec un défaut de segmentation ici.

son noté dans la "documentation":
http://labs.learnboost.com/socket.io/

sous la section serveur / écouteur Socket.IO Node.JS (effectuez une recherche sur la page pour «épissure»). Citer:

"Un tableau de clients. Important: les clients déconnectés sont définis sur null, le tableau n'est pas épissé."

Passer de la pensée au code à la documentation signifie qu'il doit y avoir une raison pour laquelle les utilisateurs déconnectés ne sont pas élagués de ce tableau, je ne peux tout simplement pas deviner quelle est cette raison. Dans le meilleur des cas, cela complique le suivi des utilisateurs CONNECTÉS et, au pire, contribue à un manque de stabilité dans l'implémentation d'un serveur node.js / socket.io.

Marqué comme un bug de performance.

J'ai le même problème.

et je fais mon numéro de base sur certains var avec i +1 pendant l'événement de connexion et -1 pendant la déconnexion. (donc ce n'est pas un problème nul)

Nombre d'utilisateurs:

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

CPU:

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

MÉMOIRE:

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

BTW.

c'est plus qu'un problème de performance, il suffit de réduire notre temps de disponibilité à moins d'une semaine.

La façon dont j'ai compris comment faire cela était d'utiliser un ensemble Redis des ID client, d'ajouter la connexion socket.io et de supprimer de l'ensemble lors de la déconnexion. La commande SCARD vous donne le nombre de clients connectés et les SMEMBRES tous les identifiants.

ouais, le tableau doit être effacé ou un meilleur moyen doit être trouvé pour contenir les clients.

+1

+1

+1
C'est certainement plus qu'un simple problème de longueur de tableau.
Incrémenter et décrémenter un compteur lors de la connexion / déconnexion entraînera toujours un compteur toujours croissant.

+1

+1

+1

+1

+1

Quelqu'un a-t-il essayé d'isoler cela aux différents transports? IE Voir si cela fonctionne de la même manière
websocket, flashsocket, interrogation xhr, etc.

C'est certainement un problème important car nous ne pouvons pas laisser le serveur fonctionner de manière cohérente sans redémarrage. Je ne peux même pas passer une journée sans au moins un redémarrage car la mémoire continue de croître. REMARQUE: dans le nœud 0.4. *, La mémoire est BEAUCOUP MEILLEURE.

+1

J'ai découvert le même problème - ma mémoire se remplit. environ 1 mb / par minute

avec environ 1500 prises qui se reconnectent en raison de clics sur le site havy.

il doit être redémarré quotidiennement à cause de la fuite de mémoire

L2C FAF IT RTFM !!!
8.0 ° ° ° ° ° ° ° ° ° ° ° ° ° °
8.0 ° ° ° ° ° █ ° ° ° ° ° ° ° ° ° ° ° °
8.0 ° ° ° ° █ ° ° ° ° ° ° ° ° ° ° °
° ° ° ° ° ° ° ° ██ ° ° ° ° ° ▄▄▄ ° °
° ░
█ °▒█▒▄ °▀▄▄▄▀ ° ° ° ° ° ° ° ° █ ° ° ° ██
█ °▒█ °█▀▄▄ ° ° ° ° ° █ ° ° ° ° ° ° ° █
° █ ▀▄ ° ▄▄▀ ° █
± ░
° ° ° ░ ° ° ° ██ ° ▀█▄▄▄█▄▄█▄████ °█ ° ° °
° ° ° ° ° ° ° ▀▀▄ ░ ° ░ █████
8.0 ° ° ° ° ° ° ° ° ° ° ° ████▄█
8.0 ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° °
8.0 ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° █ °
8.0 ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° °
8.0 ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° ° °

Je viens de désactiver le côté serveur de transport flashsocket et l'utilisation de la mémoire ET l'utilisation du processeur est tellement meilleure. Quelqu'un d'autre peut-il essayer et voir si cela aide?

+1

Je le reprends, le CPU EST MIEUX mais la mémoire fuit lentement. Je suppose que c'est parce que le serveur de stratégie flash est désactivé?

Veuillez arrêter de gonfler le flux avec "+1", ce n'est ni google plus ni facebook ...

mec je dois le faire +1 pour ça

il y a également une notification de désactivation pour ce problème ci-dessous

Dans mon cas, socket.manager.closed, socket.manager.handshaken est plus que socket.manager.open. et je ne sais pas comment effacer les connexions inutiles

Exactement la même chose ici. Nous devons redémarrer le serveur tant de fois par jour, car les connexions consomment de plus en plus de mémoire jusqu'à ce que nous manquions de 4 Go de mémoire.
Je serai très heureux si ce problème se résout, car je ne peux pas continuer à utiliser socket.io si je dois redémarrer toutes les quelques heures. (Nous avons environ 2000 utilisateurs en ligne en même temps, se connectant et se déconnectant)

J'utilise socket.io 0.9.10 et le code suivant pour déterminer le nombre de sockets:

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

Je ne sais pas avec quelle précision ce nombre réagit aux différents cas extrêmes, mais jusqu'à présent, il semble exact: chaque navigateur qui se connecte augmente le nombre, chaque navigateur fermé le diminue.

y a-t-il quelque chose qui ne va pas avec cette approche?

En mettant de côté les problèmes de comptage (qui peuvent être contournés) - les problèmes de mémoire sont assez brutaux ici. Y a-t-il un espoir que cela soit résolu à l'avenir? Cela signifie que les déploiements de socket.io de longue durée et à haute activité sont très difficiles à gérer.

Sinon, est-ce que quelqu'un connaît les fourches qui ont résolu ce problème?

Le problème est lié au code ci-dessous (extrait 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);
  };

la méthode this.socket(id) crée une nouvelle instance de socket, donc l'utiliser sur chaque socket se connecter produirait une fuite de mémoire.

@dknaus a fourni une excellente solution de contournement à cela;)

@outbounder Pouvez-vous préciser ce qu'était réellement cette excellente solution de contournement? Parce que tout ce que je vois dans ce fil est un nombre de sockets actifs

@marksyzm

 Object.keys(socketIO.connected).length;

ceci n'est valable que si vous avez un store attaché à socketio. sinon, le seul moyen de contourner est de les compter par une logique personnalisée comme ceci:

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

@outbounder mais je pensais que le but de ce bogue était de résoudre le problème de fuite de mémoire avec les sockets ne se déconnectant pas? Est-ce que je manque quelque chose?

la mémoire saigne de quelque part voir

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

Je ne sais pas si son websocket est lié, son nœud ou les deux

sockjs a des problèmes similaires - ce qui signifie qu'il pourrait soit que socket.io et sockjs utilisent la même bibliothèque ws, qui a un problème avec node - ou que ce n'est qu'un nœud général.

+1

Cela m'arrive encore en production. Je n'ai même pas autant de clients connectés, vraiment - 100-200 au maximum. Les processus sont juste à court de mémoire et suspendus ou mourants. Quelqu'un travaille-t-il sur cette fuite de mémoire? Comment puis-je aider?

Pour autant que je sache, c'est un problème connu depuis des lustres et tous ceux qui aspirent à des déploiements réels ont quitté socket.io. Il n'y a eu aucun mouvement sur ce problème, et engine.io ne semble pas du tout gâcher les cœurs de transport, il n'y a donc aucune raison de s'attendre à ce que cela corrige un jour ce problème.

Honnêtement, j'ai cherché des preuves que TOUT LE MONDE déploie vanilla socket.io en production avec un transport websocket actif et je n'ai trouvé aucun rapport fiable. Trello est un utilisateur de haut niveau, mais ils ont admis utiliser une sorte de version corrigée qui n'est pas publiée et n'utilise que le transport websocket (à quel point, pourquoi utiliser socket.io?). J'ai complètement quitté socket.io car il ne semble pas que cela va changer de sitôt. Je ne peux pas promettre que sockjs n'a aucun problème, mais je suis sûr que cela n'échouera pas aussi rapidement que socket.io si vous rejoignez / quittez quelques milliers de clients.

Je luttais juste avec ce que je pense être ce problème, sur ma propre application socket.io/redis, sur Nodejitsu. Il semble vraiment que ce soit le magasin Redis de socket.io. Je vais passer à SockJS et écrire ma propre gestion Redis, je pense.

Journaux de discussion de moi travaillant dessus dans le canal de support #nodejitsu:
https://gist.github.com/4146668

+1

Est-ce moi, ou socket.io n'utilise plus redis?

Que diriez-vous d'ajouter this.store.publish ('disconnect', id); à Manager.prototype.onClientDisconnect
comme suggéré ici: https://github.com/LearnBoost/socket.io/issues/831

Y aura-t-il des problèmes pour ajouter cette ligne? J'aime savoir.

Deuxièmement?

+1

+1

N'importe qui?

Un mouvement sur cette question? J'espère déployer dans un proche avenir et j'apprécierais vraiment tout aperçu que les personnes avec des déploiements de production ont sur ce problème.

Le correctif ci-dessus a fonctionné pour nous ... la charge a considérablement diminué
Le 4 juin 2013 à 11 h 01, "patrickod" [email protected] a écrit:

Un mouvement sur cette question? J'espère déployer dans un proche avenir et
valoriserait vraiment tout aperçu que les personnes avec des déploiements de production ont
sur cette question.

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps: //github.com/LearnBoost/socket.io/issues/463#issuecomment -18927408
.

Désactiver la prise en charge du socket flash? La documentation indique que cela est maintenant fait par défaut.

Je n'ai jamais rencontré ce problème mais je suis toujours en développement et en benchmarking. Cela a-t-il été réglé?

Tu nous as dit. Vous faites du benchmarking. :RÉ

Le jeu.23 janvier 2014 à 07h07, Maziyar Panahi [email protected] a écrit:

Je n'ai jamais rencontré ce problème mais je suis toujours en développement et en benchmarking.
Cela a-t-il été réglé?

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps: //github.com/LearnBoost/socket.io/issues/463#issuecomment -33126062
.

Tu nous as dit. Vous faites du benchmarking. :RÉ

Honnêtement, je n'ai pas remarqué de baisse en grand nombre. J'ai vu quelques connexions chuter après 5 à 6 minutes lorsque je connecte 1000 utilisateurs en même temps mais ils se reconnectent très rapidement et j'ai plus de 10K messages par seconde à tous les utilisateurs. Je pense donc que mon instance EC2 (m1.large) n'est tout simplement pas assez forte pour les maintenir toutes en vie sans en perdre quelques-unes.
Je me demandais si je ferais face à ce problème à l'avenir. Le mien en laisse tomber quelques-uns et les reconnecte dans le test de résistance. Après avoir déconnecté tout ce que je peux voir, le nombre de clients tombe à 0.

+1

Je n'ai eu aucun problème avec tout cela depuis 10.11 ... Je pourrais le mettre sur le compte d'ubuntu 10.10? Quoi qu'il en soit, ça va maintenant.