Fädeln Sie einen ereignisgesteuerten vs nicht ereignisgesteuerten Webserver ein
Die folgenden zwei Diagramme zeigen, wie Threads in einem ereignisgesteuerten Webserver (wie Node.js + JavaScript) im Vergleich zu einem nicht ereignisgesteuerten Webserver (wie IIS + C #) funktionieren.
Aus dem Diagramm ist leicht zu ersehen, dass auf einem herkömmlichen Webserver die Anzahl der Threads für die Durchführung von 3 Operationen mit langer Laufzeit größer ist als bei einem ereignisgesteuerten Webserver (3 gegenüber 1.).
Ich denke, ich habe den "traditionellen Webserver" richtig gezählt (3), aber ich wundere mich über die ereignisgesteuerte (1). Hier sind meine Fragen:
-
Ist es richtig anzunehmen, dass im ereignisgesteuerten Szenario nur ein Thread verwendet wurde? Das kann nicht stimmen, etwas muss erstellt worden sein, um die I / O-Aufgaben zu bearbeiten. Richtig?
-
Wie hat der evented Server die I / O gehandhabt? Angenommen, die E / A sollte aus einer Datenbank lesen. Ich vermute, dass der Webserver einen Thread erstellen musste, um den Job der Verbindung mit der Datenbank zu übergeben? Richtig?
-
Wenn der ereignisgesteuerte Webserver tatsächlich Threads erstellt hat, um die E / A zu handhaben, wo ist die Verstärkung?
-
Eine mögliche Erklärung für meine Verwirrung könnte sein, dass in beiden Szenarien, traditionelle und ereignisgesteuerte drei separate Threads tatsächlich erstellt wurden, um die I / O zu handhaben (nicht in den Bildern gezeigt) ), aber der Unterschied liegt tatsächlich in der Anzahl der Threads auf dem Webserver selbst, nicht in den E / A-Threads. Ist das genau?
2 Antworten
-
Knoten kann Threads für IO verwenden. Der JS-Code wird in einem einzelnen Thread ausgeführt, aber alle E / A-Anforderungen werden in parallelen Threads ausgeführt. Wenn Sie möchten, dass ein JS-Code in parallelen Threads ausgeführt wird, verwenden Sie thread-a-gogo oder einige andere Pakete, die dieses Verhalten mindern.
-
Wie
1., Threads werden von Node für IO-Operationen erstellt. -
Sie müssen Threading nicht verarbeiten, es sei denn, Sie möchten es tun. Leichter zu entwickeln. Zumindest ist das mein Standpunkt.
-
Eine Knotenanwendung kann so codiert werden, dass sie wie ein anderer Webserver ausgeführt wird. In der Regel wird JS-Code in einem einzelnen Thread ausgeführt, es gibt jedoch Möglichkeiten, das Verhalten anders zu gestalten.
Persönlich empfehle ich threads-a-gogo (der Paketname ist nicht so aufschlussreich, aber es ist einfach zu verwenden), wenn Sie mit Threads experimentieren wollen. Es ist schneller. Knoten unterstützt auch mehrere Prozesse, Sie können einen komplett separaten Prozess ausführen, wenn Sie das auch ausprobieren möchten.
Der beste Weg, sich NodeJS vorzustellen, ist wie ein wütendes Eichhörnchen (d. h. Ihr Thread), das in einem Rad mit einer unendlichen Anzahl von Tauben (Ihrem I / O) läuft, um Nachrichten weiterzugeben.
E / A im Knoten ist "frei". Ihr Eichhörnchen arbeitet daran, die Verbindung aufzubauen und die Taube abzuschalten, dann kann es andere Dinge tun, während die Taube die Daten abruft und sich nur mit den Daten beschäftigt, wenn die Taube zurückkehrt.
Wenn Sie schlechten Code schreiben, können Sie am Ende das Eichhörnchen auf jede Taube warten lassen.
Schreiben Sie also immer nicht blockierenden E / A-Code.
Wenn Sie Ihre Tauben dazu ermutigen können, zurückzukommen;)
Versprechen und Generatoren sind wahrscheinlich der beste Ansatz, den Sie dabei anwenden können.
JEDOCH können Sie Knoten Cluster immer verwenden, um ein Master Eichhörnchen zu etablieren, das Kind Eichhörnchen basierend auf der Anzahl von CPUs, die das Eichhörnchen finden kann, um die Arbeit zu verteilen.
Hoffe, das hilft und merkt das völlige Fehlen einer Autoanalogie.
Tags und Links node.js