Socket.io: Anzahl der verbundenen Clients / Sockets

+1. Ich denke in meinem Fall ist dies ein letztes Problem, das Speicherprobleme verursacht (wächst bis zum Segmentierungsfehler).

Ja, stürzt hier ungefähr zweimal am Tag mit einem Segmentierungsfehler ab.

es ist in der "Dokumentation" vermerkt:
http://labs.learnboost.com/socket.io/

im Abschnitt Socket.IO Node.JS Server / Listener (In-Page-Suche nach "Spleiß" durchführen). Zitieren:

"Ein Array von Clients. Wichtig: Nicht verbundene Clients werden auf null gesetzt, das Array wird nicht gespleißt."

Um vom Gedanken über den Code bis zur Dokumentation zu gelangen, muss es einen Grund geben, warum nicht verbundene Benutzer nicht aus diesem Array entfernt werden. Ich kann nur nicht erraten, was dieser Grund ist. Das beste Szenario ist, dass es das Verfolgen von CONNECTED-Benutzern zu einem Problem macht und im schlimmsten Fall zu einem Mangel an Stabilität in einer node.js / socket.io-Serverimplementierung beiträgt.

Als Leistungsfehler markiert.

Ich habe das gleiche Problem.

und ich mache meine Nummer basierend auf einem var mit i +1 während des Verbindungsereignisses und -1 während des Trennens. (Das ist also kein Nullproblem)

Benutzeranzahl:

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

ZENTRALPROZESSOR:

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

ERINNERUNG:

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

Übrigens.

Es ist mehr als ein Leistungsproblem, es senkt nur unsere Betriebszeit auf weniger als eine Woche.

Die Art und Weise, wie ich das herausgefunden habe, bestand darin, einen Redis-Satz der Client-IDs zu verwenden, die Verbindung zu socket.io hinzuzufügen und beim Trennen aus dem Satz zu entfernen. Mit dem Befehl SCARD erhalten Sie die Anzahl der verbundenen Clients und SMEMBERS alle IDs.

Ja, das Array muss gelöscht werden oder es muss ein besserer Weg gefunden werden, um Clients zu halten.

+1

+1

+1
Dies ist definitiv mehr als nur ein Problem mit der Array-Länge.
Das Inkrementieren und Dekrementieren eines Zählers beim Verbinden / Trennen führt immer noch zu einem immer größeren Zähler.

+1

+1

+1

+1

+1

Hat jemand versucht, dies auf die verschiedenen Transporte zu isolieren? IE Überprüfen Sie, ob es in funktioniert
Websocket, Flashsocket, Xhr-Polling usw.

Dies ist definitiv ein wichtiges Problem, da der Server ohne Neustart nicht konsistent laufen kann. Ich kann nicht einmal einen Tag ohne mindestens einen Neustart verbringen, da der Speicher weiter wächst. HINWEIS: In Knoten 0.4. * Ist der Speicher für mich VIEL BESSER.

+1

Ich habe das gleiche Problem entdeckt - mein Gedächtnis wird gerade voll. etwa 1 mb / pro Minute

mit ca. 1500 Steckdosen, die sich aufgrund von Klicks auf der Website wieder verbinden.

Aufgrund des Speicherverlusts muss es täglich neu gestartet werden

L2C FAF IT RTFM !!!
░░░░░▄▄▄▄▀▀▀▀▀▀▀▀▄▄▄▄▄▄░░░░░░░░
░░░░░█░░░░▒▒▒▒▒▒▒▒▒▒▒▒░░▀▀▄░░░░
░░░░█░░░▒▒▒▒▒▒░░░░░░░░▒▒▒░░█░░░
░░░█░░░░░░▄██▀▄▄░░░░░▄▄▄░░░░█░░
░▄▀▒▄▄▄▒░█▀▀▀▀▄▄█░░░██▄▄█░░░░█░
█░▒█▒▄░▀▄▄▄▀░░░░░░░░█░░░▒▒▒▒▒░█
█░▒█░█▀▄▄░░░░░█▀░░░░▀▄░░▄▀▀▀▄▒█
░█░▀▄░█▄░█▀▄▄░▀░▀▀░▄▄▀░░░░█░░█░
░░█░░░▀▄▀█▄▄░█▀▀▀▄▄▄▄▀▀█▀██░█░░
░░░█░░░░██░░▀█▄▄▄█▄▄█▄████░█░░░
░░░░█░░░░▀▀▄░█░░░█░█▀██████░█░░
░░░░░▀▄░░░░░▀▀▄▄▄█▄█▄█▄█▄▀░░█░░
░░░░░░░▀▄▄░▒▒▒▒░░░░░░░░░░▒░░░█░
░░░░░░░░░░▀▀▄▄░▒▒▒▒▒▒▒▒▒▒░░░░█░
░░░░░░░░░░░░░░▀▄▄▄▄▄░░░░░░░░█░░
░░░░░░░░░░░░░░░░░░░░▀▀▀▀▀▀▀▀░░░

Ich habe gerade die Flashsocket-Transportserverseite ausgeschaltet und die Speichernutzung UND die CPU-Nutzung sind SO VIEL BESSER. Kann jemand anderes das ausprobieren und sehen, ob das hilft?

+1

Ich nehme es zurück, die CPU ist besser, aber der Speicher leckt immer noch langsam. Ich nehme an, das liegt daran, dass der Flash-Richtlinienserver ausgeschaltet wird.

Bitte hör auf, den Feed mit "+1" aufzublähen, dies ist weder Google Plus noch Facebook ...

Mann, ich muss es tun +1 dazu

Es gibt auch eine Deaktivierungsbenachrichtigung für dieses Problem

In meinem Fall ist socket.manager.closed, socket.manager.handshaken mehr als socket.manager.open. und ich weiß nicht, wie ich die nutzlosen Verbindungen klären soll

Genau das gleiche hier. Wir müssen den Server so oft pro Tag neu starten, weil die Verbindungen immer mehr Speicher verbrauchen, bis uns 4 GB Speicher ausgehen.
Ich werde mich sehr freuen, wenn dieses Problem behoben ist, da ich socket.io nicht weiter verwenden kann, wenn ich alle paar Stunden neu starten muss. (Wir haben ungefähr 2000 Online-Benutzer gleichzeitig, die eine Verbindung herstellen und trennen.)

Ich verwende socket.io 0.9.10 und den folgenden Code, um die Anzahl der Sockets zu bestimmen:

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

Ich bin mir nicht sicher, wie genau diese Zahl auf die verschiedenen Randfälle reagiert, aber bis jetzt scheint sie genau zu sein: Jeder Browser, der eine Verbindung herstellt, erhöht die Zahl, jeder geschlossene Browser verringert sie.

Stimmt etwas mit diesem Ansatz nicht?

Abgesehen von den Zählproblemen (die umgangen werden können) - die Speicherprobleme sind hier ziemlich brutal. Gibt es Hoffnung, dass dies in Zukunft behoben wird? Dies bedeutet, dass Socket.io-Bereitstellungen mit langer Laufzeit und hoher Aktivität sehr schwierig zu verwalten sind.

Kennt jemand Gabeln, bei denen dieses Problem behoben wurde?

Das Problem hängt mit dem folgenden Code zusammen (entnommen aus 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);
  };

Die Methode this.socket(id) erstellt eine neue Instanz des Sockets. Wenn Sie diese also bei jeder Socket-Verbindung verwenden, führt dies zu einem Speicherverlust.

@dknaus lieferte eine hervorragende

@outbounder Kannst du darauf hinweisen, was diese hervorragende Problemumgehung tatsächlich war? Denn alles, was ich in diesem Thread sehe, ist eine aktive Socket-Anzahl

@marksyzm

 Object.keys(socketIO.connected).length;

Dies gilt nur, wenn Sie ein Geschäft an socketio angeschlossen haben. Andernfalls können Sie sie nur nach benutzerdefinierter Logik wie folgt zählen:

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

@outbounder, aber ich dachte, der Sinn dieses Fehlers besteht darin, das Problem mit dem Speicherverlust zu beheben, wenn die Sockets nicht getrennt werden. Vermisse ich etwas

Erinnerung blutet irgendwo aus

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

Unsicher, ob es sich um einen Websocket oder einen Knoten handelt oder beides

sockjs hat ähnliche Probleme - was bedeutet, dass entweder socket.io und sockjs dieselbe ws lib verwenden, die ein Problem mit node hat - oder es handelt sich nur um ein allgemeines Knotenproblem

+1

Das passiert mir immer noch in der Produktion. Ich habe nicht einmal so viele verbundene Clients, wirklich - 100-200 in der Spitze. Prozesse haben nur noch wenig Speicher und hängen oder sterben. Arbeitet jemand an diesem Speicherverlust? Wie kann ich helfen?

Soweit ich das beurteilen kann, ist dies seit Jahrhunderten ein bekanntes Problem, und jeder, der nach tatsächlichen Bereitstellungen strebt, hat sich von socket.io entfernt. Es gab keine Bewegung in dieser Angelegenheit, und die engine.io scheint überhaupt nicht mit den Transportkernen zu spielen, daher gibt es keinen Grund zu der Annahme, dass dies auch jemals behoben wird.

Ehrlich gesagt habe ich nach Beweisen gesucht, dass JEDER Vanilla Socket.io in der Produktion mit einem aktiven Websocket-Transport einsetzt und keine zuverlässigen Berichte gefunden hat. Trello ist ein hochkarätiger Benutzer, aber er hat zugegeben, eine gepatchte Version zu verwenden, die nicht veröffentlicht wurde und nur den Websocket-Transport verwendet (ab wann sollte überhaupt socket.io verwendet werden?). Ich habe socket.io komplett verlassen, weil es nicht so aussieht, als würde sich dies bald ändern. Ich kann nicht versprechen, dass sockjs keine Probleme hat, aber ich bin mir sicher, dass es nicht annähernd so schnell ausfällt wie socket.io, wenn Sie ein paar tausend Kunden beitreten / verlassen.

Ich habe gerade mit dem gerungen, was ich für dieses Problem halte, auf meiner eigenen socket.io/redis App auf Nodejitsu. Es scheint definitiv so, als wäre es der Redis Store von socket.io. Ich werde zu SockJS wechseln und mein eigenes Redis-Management schreiben, denke ich.

Chat-Protokolle von mir, die im Support-Kanal #nodejitsu daran arbeiten:
https://gist.github.com/4146668

+1

Bin ich es oder benutzt socket.io keine Redis mehr?

Wie wäre es mit dem Hinzufügen von this.store.publish ('trennen', ID); zu Manager.prototype.onClientDisconnect
wie hier vorgeschlagen: https://github.com/LearnBoost/socket.io/issues/831

Wird es Probleme beim Hinzufügen dieser Zeile geben? Ich würde gerne wissen.

Zweitens das?

+1

+1

Jemand?

Irgendeine Bewegung zu diesem Thema? Ich hoffe, dass ich in naher Zukunft bereitstellen kann, und würde jeden Einblick, den Mitarbeiter mit Produktionsbereitstellungen zu diesem Thema haben, wirklich schätzen.

Fix oben hat bei uns funktioniert ... Last ist deutlich gesunken
Am 4. Juni 2013, 11:01 Uhr, schrieb "patrickod" [email protected] :

Irgendeine Bewegung zu diesem Thema? Ich hoffe, in naher Zukunft und zu implementieren
Ich würde jeden Einblick, den Menschen mit Produktionsbereitstellungen haben, wirklich schätzen
zu diesem Thema.

- -
Antworten Sie direkt auf diese E-Mail oder sehen Sie sie sich unter Gi tHubhttps an: //github.com/LearnBoost/socket.io/issues/463#issuecomment -18927408
.

Flash-Socket-Unterstützung deaktivieren? Die Dokumentation besagt, dass dies jetzt standardmäßig erfolgt.

Ich habe mich diesem Problem noch nie gestellt, bin aber noch in der Entwicklung und im Benchmarking. Wurde das geklärt?

Du erzählst uns. Sie machen Benchmarking. : D.

Am Donnerstag, 23. Januar 2014, um 7:07 Uhr schrieb Maziyar Panahi [email protected] :

Ich habe mich diesem Problem noch nie gestellt, bin aber noch in der Entwicklung und im Benchmarking.
Wurde das geklärt?

- -
Antworten Sie direkt auf diese E-Mail oder sehen Sie sie sich auf Gi tHubhttps an: //github.com/LearnBoost/socket.io/issues/463#issuecomment -33126062
.

Du erzählst uns. Sie machen Benchmarking. : D.

Ehrlich gesagt habe ich nicht bemerkt, dass ich in großer Zahl gefallen bin. Ich habe gesehen, dass nach 5 bis 6 Minuten nur wenige Verbindungen unterbrochen wurden, wenn ich 1000 Benutzer gleichzeitig verbinde, aber sie stellen die Verbindung sehr schnell wieder her und ich habe über 10.000 Nachrichten pro Sekunde an alle Benutzer. Daher denke ich, dass meine EC2-Instanz (m1.large) einfach nicht stark genug ist, um sie alle am Leben zu erhalten, ohne nur wenige fallen zu lassen.
Ich habe mich gefragt, ob ich in Zukunft mit diesem Problem konfrontiert werde. Meins lässt nur wenige fallen und verbindet sie im Stresstest wieder. Nachdem ich alle getrennt habe, kann ich sehen, dass die Anzahl der Clients auf 0 fällt.

+1

Ich hatte seit 10.11 keine Probleme damit ... Ich würde es möglicherweise auf die Verwendung von Ubuntu 10.10 zurückführen? Wie auch immer, scheint jetzt in Ordnung zu sein.