Hier ist mein Beispielcode:
%Vor%Was ich herausgefunden habe, ist, dass wenn ich eine Verbindung zu einem anderen Server herstelle (Google oder irgendwas anderes), die Antwort langsamer und langsamer bis zu einigen Sekunden wird. Es passiert nicht, wenn ich eine Verbindung zu einem anderen node.js Server innerhalb desselben Netzwerks herstelle.
Ich benutze JMeter zum Testen. 50 gleichzeitige pro Sekunde mit 1000 Schleife.
Ich habe keine Ahnung, was das Problem ist ...
==========================
Weitere Untersuchung:
Ich führe das gleiche Skript auf Rackspace und auch auf EC2 zum Testen. Und das Skript verwendet http.request, um eine Verbindung herzustellen mit: Google, Facebook und auch meinem anderen Skript, das einfach Daten (wie Hallo Welt) ausgibt, die von einer anderen EC2-Instanz gehostet werden.
Das Testwerkzeug Ich bin gerade jMeter auf meinem Desktop.
pre-node.js-Test: jMeter - & gt; Google Ergebnis: schnell und konsistent. jMeter - & gt; Facebook-Ergebnis: schnell und konsistent. jMeter - & gt; Mein Simple Output Script Ergebnis: schnell und konsistent.
Dann mache ich 50 Concurrent Threads / Sek. mit 100 Loops, testet zu meinen Rackspace Nodejs und dann EC2 node.js, welches das gleiche King of Performance Problem hat
jMeter - & gt; node.js - & gt; Google Ergebnis: ab 50 ms geht 2000 in 200 requsets.
jMeter - & gt; node.js - & gt; Facebook Ergebnis: ab 200 ms geht es nach 200 requsets bis 3000 ms.
jMeter - & gt; node.js - & gt; Mein Simple Output Script Ergebnis: von 100 ms geht nach 200 requsets auf 1000 ms.
Die ersten 10-20 Anfragen sind schnell und beginnen dann langsamer zu werden.
Wenn ich dann zu 10 Concurrent Threads wechsle, beginnen die Dinge sich zu ändern. Die Antwort ist sehr konsistent, keine Verlangsamung.
Etwas mit # gleichzeitig ablaufenden Threads, die Node.js (http.request) verarbeiten kann.
------------ Mehr --------------
Ich habe heute mehr Tests gemacht und hier ist es: Ich habe http.Agent benutzt und den max-Socket erhöht. Das Interessante ist jedoch, dass es sich auf einem Testserver (EC2) sehr verbessert und nicht mehr verlangsamt. Aber der andere Server (Rackspace) verbessert nur ein bisschen. Es zeigt immer noch langsam. Ich habe sogar "Verbindung: Schließen" im Request-Header gesetzt, es verbessert nur 100ms.
Wenn http.request Verbindungspooling verwendet, wie kann es erhöht werden?
in beiden Servern, wenn ich "ulimit -a" mache, ist die Anzahl der geöffneten Dateien 1024.
------------- ** MEHR UND MEHR ** -------------------
Es scheint, dass selbst wenn ich maxSockets auf eine höhere Nummer gesetzt habe, es nur an einem Limit funktioniert. Es scheint eine interne oder Betriebssystem abhängige Socket-Beschränkung zu geben. Aber um es aufzusteigen?
------------- ** NACH UMFANGREICHER PRÜFUNG ** ---------------
Nachdem ich viel Post gelesen habe, finde ich heraus:
zitiert aus: Ссылка
1) Wenn ich die Header mit connection = 'keep-alive' setze, ist die Leistung gut und kann bis zu maxSocket = 1024 gehen (was meine Linux-Einstellung ist).
%Vor%Wenn ich es auf "Connection": "close" setze, wäre die Reaktionszeit 100 mal langsamer.
Lustige Dinge sind hier passiert:
1) in EC2, wenn ich zuerst mit Connection: keep-alive teste, dauert es etwa 20-30 ms. Wenn ich dann zu "Verbindung: Schließen" oder "Agent: false" wechsle, wird die Reaktionszeit auf 300 ms verringert. WIHTOUT Neustart des Servers, wenn ich zu Connection: keep-alive wieder wechsle, wird die Reaktionszeit noch weiter auf 4000ms verlangsamen. Entweder muss ich den Server neu starten oder eine Weile warten, bis ich meine Reaktionszeit von 20-30ms erreicht habe.
2) Wenn ich es mit agent: false starte, wird sich die Reaktionszeit zunächst auf 300ms verlangsamen. Aber dann wird es wieder schneller und wieder "normal".
Meine Vermutung ist, dass das Verbindungs-Pooling noch in Kraft ist, selbst wenn Sie den Agenten gesetzt haben: false. Wenn Sie jedoch die Verbindung halten: keep-alive, dann wird es schnell sicher sein. schalte es einfach nicht um.
Aktualisierung am 25. Juli 2011
Ich habe die neueste node.js V0.4.9 mit der http.js & amp; https.js beheben von Ссылка
die Leistung ist viel besser und stabil.
Dies wird Ihr Problem nicht unbedingt beheben, aber es räumt Ihren Code etwas auf und nutzt die verschiedenen Ereignisse wie Sie sollten:
%Vor%Ich habe die Ausgabe des Körpers entfernt. Da wir von einem Sockel zu einem anderen strömen, können wir nicht sicher sein, den ganzen Körper zu jeder Zeit zu sehen, ohne ihn zu puffern.
BEARBEITEN: Ich glaube, Knoten verwendet Verbindungspooling für http.request. Wenn Sie 50 gleichzeitige Verbindungen (und damit 50 gleichzeitige http.Request-Versuche) haben, stoßen Sie möglicherweise auf den Limit des Verbindungspools. Ich habe derzeit keine Zeit, das für Sie zu suchen, aber Sie sollten sich die Node-Dokumentation in Bezug auf http, insbesondere http-Agent ansehen.
BEARBEITEN SIE 2: Es gibt einen Thread zu a sehr ähnliches Problem auf der Mailingliste node.js. Sie sollten es sich ansehen, besonders Mikaels Beitrag sollte interessant sein. Er schlägt vor, das Verbindungspooling für die Anforderungen vollständig zu deaktivieren, indem die Option agent: false an den Aufruf http.request übergeben wird. Ich habe keine weiteren Hinweise, wenn das nicht hilft, sollten Sie vielleicht versuchen, Hilfe auf der node.js Mailingliste zu bekommen.
Github-Ausgabe 877 kann verwandt sein:
Obwohl es mir nicht klar ist, ob Sie das treffen. Die "agent: false" -Arbeitsumgehung funktionierte für mich, als ich dies traf, ebenso wie das Setzen eines Headers "connection: keep-alive" mit der Anfrage.
Ich hatte mit dem gleichen Problem zu kämpfen. Ich habe meinen Engpass als DNS-Kram gefunden, obwohl ich nicht genau weiß, wo / warum. Wenn ich meine Anfragen an etwas wie Ссылка mache, kann ich kaum 50-100 rq / s laufen und wenn ich über 100 rq / s gehe und mehr Dinge werden zur Katastrophe, die Antwortzeiten werden groß und einige Anfragen enden nie und warten auf unbestimmte Zeit und ich muss meinen Server töten. Wenn ich die Anfragen an die IP-Adresse des Servers mache, ist alles bei 500 rq / s stabil, wenn auch nicht gerade glatt und der Graph (ich habe Echtzeitgraph) ist spitz. Und bedenke, dass die Anzahl der geöffneten Dateien in Linux immer noch begrenzt ist und ich es geschafft habe, es einmal zu treffen. Eine weitere Beobachtung ist, dass ein Einzelknotenprozess nicht glatt 500 rq / s erzeugen kann. Aber ich kann 4-Knoten-Prozesse starten, die jeweils 200 rq / s machen, und ich bekomme sehr glatte Graphen und konsistente CPU / Netzlast und sehr kurze Antwortzeiten. Dies ist Knoten 0.10.22.
Tags und Links node.js http request load-testing