5

Ich kann nicht herausfinden, was die Ursache für den Engpass auf dieser Website ist, sehr schlechte Antwortzeiten, sobald etwa 400 Benutzer erreicht. Die Website befindet sich in der Google Compute Engine und verwendet eine Instanzgruppe mit Netzwerklastenausgleich. Wir haben das Projekt mit sailjs erstellt.
Ich habe Lasttests mit Google Container-Engine mit kubernetes durchgeführt und das Skript locust.py ausgeführt.Laden Test Engpass auf Nodejs mit Google Compute Engine

Die wichtigsten Ergebnisse für einen der Tests sind:

RPS : 30 
Spawn rate: 5 p/s 
TOTALS USERS: 1000 
AVG(res time): 27500!! (27,5 seconds) 

Die Reaktionszeit unter einer Sekunde zunächst groß ist, aber wenn es beginnt etwa 400 Benutzer die Antwortzeit beginnt Erreichen massiv zu springen.

Ich habe offensichtliche Faktoren getestet, die die Reaktionszeit beeinflussen können, ergibt sich unter:

Compute Engine-Instanzen (2 x Standard-n2, 200GB Festplatte, RAM: 7.5GB pro Instanz):

Only about 20% cpu utilization used 
Outgoing network bytes: 340k bytes/sec 
Incoming network bytes: 190k bytes/sec 
Disk operations: 1 op/sec 
Memory: below 10% 

MySQL:

Max_used_connections : 41 (below total possible) 
Connection errors: 0 

Alle Andere Ergebnisse für MySQL scheinen ebenfalls in Ordnung zu sein, kein Grund für Engpässe.

Ich habe den gleichen Test für ein neues sailjs erstellt Projekt versucht, und es hat besser, aber immer noch schreckliche Ergebnisse, 5 Sekunden Res-Zeit für etwa 2000 Benutzer.

Was sollte ich noch testen? Was könnte der Flaschenhals sein?

+1

Es ist wahrscheinlich in Ihrem node.js-Code. Wahrscheinlich etwas synchrones Blockieren der Ereignisschleife, die beim Hochfahren von Anfragen/Sekunde explodiert. Probieren Sie es aus. – bbuckley123

+0

Danke. Ich habe eine Menge Leute gefunden, die sagen, dass globalAgent.maxSockets ein Problem sein kann. Der aktuelle Standardwert ist 5. Könnte dies der Grund sein? @ bbuckley123 – cfl

+0

Der Standard ist eigentlich Infinity. So war es für mehrere Knoten-Releases: https://nodejs.org/api/http.html#http_agent_maxsockets – bbuckley123

Antwort

3

Machst du eine Datei lesen/schreiben? Dies ist ein großes Hindernis in node.js und wird immer einige Probleme verursachen. Caching Lesen von Dateien oder Entfernen der Notwendigkeit für solchen Code sollte so viel wie möglich getan werden. Meiner Erfahrung nach würde das Bereitstellen von Dateien wie Bildern, CSS, JS und dergleichen über meinen Node-Server Probleme verursachen, wenn die Anzahl der gleichzeitigen Anfragen erhöht würde. Die Lösung sollte all dies über ein CDN bieten.

Ein weiterer Problem könnte der mysql-Treiber sein. Wir hatten einige Probleme damit, dass die Verbindung nicht korrekt geschlossen wurde (ich benutze sails.js nicht, aber ich glaube, sie benutzten den gleichen Treiber zum Zeitpunkt, als ich auftrat), sie würden Probleme auf dem mysql-Server verursachen, was zu langen Verzögerungen beim Abrufen von Daten führte aus der Datenbank. Sie sollten die Anzahl der MySQL-Abfragen nachverfolgen und sicherstellen, dass sie nicht verzögert werden.

Schließlich könnte es ein spezielles Problem mit sails.js und Google Compute Engine sein. Sie sollten sicherstellen, dass es keine offenen Probleme auf beiden Seiten gibt, die das gleiche Problem betreffen.

+0

Kaum Lesen/Schreiben in unserem Projekt und auch das brandneue sailsjs-Projekt "bombardiert", das grundsätzlich nicht liest/schreibt. Obwohl CDN bei der Optimierung hilft, zeigt es nicht, warum unsere Ergebnisse so schlecht sind. Ich überprüfte die mysql-Instanz, keine Engpässe dort, kaum Lese-/Schreibvorgänge. Wie bereits erwähnt, haben wir das brandneue Projekt sailsjs ausprobiert, das keine DB-Abfragen verwendet. Der letzte Punkt, den Sie erwähnt haben, ist möglich, ich habe noch nichts gefunden, werde aber weiter suchen. Vielen Dank für Ihre Antwort – cfl

+0

@cfl, senden Sie POST oder GET-Anfragen (ich habe irgendwo über ein Problem mit POST in sails.js gelesen)? Könnten Sie ein Repo erstellen, um zu zeigen, was genau Sie tun? – amberv

+0

Ja, das verwenden wir für unsere Anfragen. Wir verwenden das in unserer Datei routes.js. Was für ein Problem war das, erinnerst du dich vielleicht? Shucks das Repo ist ein hartes soz, wegen der geistigen Eigentumsfragen, die ich habe. Was genau willst du im Repo? Aber um eine Vorstellung von dem Fluss zu bekommen, verwenden wir sails.get ("/ get_info", Nachricht), die dann routes.js durchläuft, um die Controller-Methode aufzurufen. Die Controller-Methode führt dann die Datenbankabfragen usw. mit der Wasserlinie durch und antwortet dann zurück. @amberv – cfl

Verwandte Themen