Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

Node.js für ASP.NET-Entwickler

So funktioniert der Node.js-Web-Server

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Der Aufbau der Node.js-Architektur unterscheidet sich grundlegend von dem eines klassischen Web-Servers. Event Queue, Event Loop, aber auch ein Internal Thread Pool sorgen dafür, dass der Modus funktioniert.

Transkript

Jetzt nach reichlich viel Vorbereitungen durch die anderen Videos können wir endlich genauer sehen, wie so ein Node.js Web-Server exakt funktioniert, und zwar eben auch aus Architektursicht, und zum Vergleich vom klassischen Web-Server sehen wir hier schon mal einen ganz anderen Aufbau. Erst mal sehen wir wieder einen Event Queue, also wieder einen Warteschlangenbereich, und dann haben wir hier eben einen einzigen Thread, der läuft mit einem Event Loop. Und dann haben wir dennoch auch ein Node.js Internal Thread Pool. Also ist es sehr, sehr spannend. Schauen wir uns doch mal an, wie das Ganze eben zur Laufzeit dann funktioniert. Auch hier haben wir die gleichen Clients, die zur gleichen Zeit Anfragen an den Web-Server stellen, und diese werden erstmal zu Beginn eben in den Event Queue aufgenommen, in den Warteschlangenbereich. Und die werden natürlich der Reihe nach wieder abgearbeitet, und zwar durch den großen Manager, durch den Event Loop. Der sieht nämlich, dass der Call Stack hier, zum Beispiel, gerade nichts zu tun hat. Sagen wir mal, der Call Stack wäre jetzt exakt in der Mitte. Das heißt, er schnappt sich natürlich den ersten Request, und der wird jetzt genauer analysiert, das heißt, dann wird da schon mal der Code ausgeführt. Und sobald innerhalb vom Code ein Input-/Output-Vorgang stattfindet, wie zum Beispiel das auf eine Datenbank zugegriffen werden muss oder das irgendwo auf die Dateien von Betriebssystemen zugegriffen werden muss, dann wird sofort das Ganze hier wieder an das System ausgelagert in einen eigenen Thread, und zwar von dem Node.js internal Thread Pool. Und der hat oft auch schon fertige Threads vorbereitet, das heißt, es wird nicht immer ein neuer erzeugt, sondern die werden auch gerne wieder verwendet. Und somit kann das blitzschnell einfach wieder abgegeben werden, diese Arbeit. Und der Event Loop ist jetzt wieder frei, das heißt, der Call Stack, der hat jetzt nichts mehr zu tun. Der schnappt sich natürlich wieder die nächste Anfrage, Sieht, okay: Hier ist wieder ein Blocking-IO-Vorgang. Hier wird dann das Ganze wieder in einem eigenen Thread ausgelagert. Dann haben wir hier, zum Beispiel, Request. Das wird dann auch wieder in einem eigenen Thread ausgelagert. Und sagen wir mal, die 400. Anfrage hier tut einfach nur plain JavaScript Logik ausführen. Da wird irgendwas einfach nur in einem bestimmten Algorithmus berechnet, aber ohne dass irgendwo ein Input-/Output-Vorgang stattfindet, und somit wird sofort natürlich, deren Verarbeitung vorgenommen innerhalb vom Call Stack. Und in der Zwischenzeit können nämlich die ganzen anderen Threads, die irgendwelche Input-/Output-Parameter möchten, werden dann ausgeführt, und in der Zwischenzeit kann der Call Stack also sich eben einfach nur um diese einfache JavaScript-Funktion kümmern und kann dann sofort die Antwort an den Client zurückgeben. Und kommt jetzt die Antwort zurück vom System, dann sehen wir hier schon mal, dass der Call Stack gerade nichts zu tun hat. Also, kann der Event Loop das dem Call Stack sofort zuweisen, dann wird das Ganze sofort verarbeitet. Und jetzt kommen wir zu dem Szenario. Wo viele eben dann zweifeln, funktioniert das überhaupt auch unter Node.js mit diesem Prinzip hier. Und zwar kommt jetzt noch eine weitere Antwort aus dem System zurück, und der Call Stack ist aber gerade besetzt. Er arbeitet gerade eben die blauen Request ab. In dem Fall wird automatisch dieser Response durch den Event Loop, also der Event Loop ist nichts Anderes wie eine While-Schleife. So kann man sich das vorstellen. Der liegt automatisch einfach diesen Response in den Event Queue wieder ab. Das heißt, du kommst wieder in Warteschlangenbereich. Wir haben gerade etwas im Call Stack. Das muss erst abgearbeitet werden. Wenn das fertig ist, dann schnappe ich dich innerhalb von meiner Schleife wieder aus dem Warteschlangenbereich und verarbeite deinen restlichen Code, und danach kann der Client hier die Antwort wieder bekommen. Am Ende bekommen wir hier vom dritten Thread nochmal das Ergebnis. Da jetzt eben der Call Stack komplett frei ist, kann eben schon mal alles wieder verarbeitet werden und die Antwort zurückgesendet werden. Und durch dieses eine Prinzip hier, obwohl wir hier nur einen einzigen Thread haben, worauf alles läuft, ist es am Ende performanter, als wenn jedes Mal ein eigener Thread erzeugt werden müsste. Und alle lang andauernden Prozesse, dafür gibt es dann schon fertige Threads oder diese müssten dann im Backend trotzdem neu erzeugt werden, stören nicht, wenn einfacher JavaScript-Code im Vordergrund dann ausgeführt werden muss. Und das ist das, was hier wirklich bremst: dieses Erzeugen von Threads, das Synchronisieren, weil das Ausführen von einfachen JavaScript-Code geht extrem schnell. Also es gibt ganz, ganz selten Szenarien, wo man sagt, unser Algorithmus ist so komplex, dass dieser von der Verarbeitung extrem lange dauert. Ist das aber der Fall, ist Node.js nicht die richtige Lösung. Und da muss man wirklich abmessen: Ist das hier was Zeit beansprucht der Zugriff auf die Datenbank? Das Speichern auf der Datenbank oder der Aufruf von Web-Services oder auf System, das sind alles Blocking-IO-Vorgänge, die viel Zeit kosten. Wenn das nicht der Fall ist, und der Algorithmus trotzdem lange braucht im eigenen ASP.NET-Code oder im JavaScript-Code, dann ist Node.js nicht die Lösung. Ansonsten ist das das Geheimnis, warum Node.js schneller ist wie gängige Web-Server-Architekturen.

Node.js für ASP.NET-Entwickler

Sehen Sie, wie Sie den Umstieg auf auf native JavaScript-Entiwcklung mit Node.js erfolgreich meistern.

2 Std. 52 min (31 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Exklusiv für Abo-Kunden
Ihr(e) Trainer:
Erscheinungsdatum:15.05.2017
Laufzeit:2 Std. 52 min (31 Videos)

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!