Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

Node.js für ASP.NET-Entwickler

So funktionieren "klassische" Web-Server

Testen Sie unsere 2019 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Klassische Web-Server wie IIS, Apache oder Tomcat behandeln jede Anfrage als eigenen Thread. Das Erzeugen von Threads und die Synchronisierung der Prozesse kosten viel Zeit und Energie. Der Vorteil ist, dass die Threads unabhängig voneinander laufen.

Transkript

Um genau verstehen zu können, wie Node.js als Web-Server technisch funktioniert und wie Node.js mit vielen Anfragen so gut umgehen kann gleichzeitig, müssen wir auch erst mal verstehen, wie funktionieren denn klassische Web-Server wie zum Beispiel Apache, Tomcat oder die Internetinformationsdienste, wo eben häufig ASP.NET gehostet wird. Und das schauen wir uns jetzt genauer an, und zwar sehen wir hier eben die Architektur einmal abgebildet. Wir sehen ganz links eine Vielzahl von unterschiedlichen Clients. Die benutzen alle ihren beliebigen Browser: Internet Explorer, Chrome, Firefox. Das spielt gar keine Rolle. Auf jeden Fall rufen die alle zur gleichen Zeit unseren Web-Server auf, und zwar bekommen wir eben zur gleichen Zeit unterschiedliche Anfragen, "Requests". Und diese nimmt der Web-Server eben entgegen in einem sogenannten Thread Pool. Das bedeutet, jede Anfrage würde jetzt eben als eigenständiger Thread behandelt. Und der Thread, zum Beispiel, von der allerersten Anfrage da wird die Verarbeitung direkt dann mit dem Backend, zum Beispiel, zusammen kommuniziert. Das bedeutet, die Anfrage greift auf die Datenbank zu. Der nächste Thread, der will auch irgendwelche Daten aus der Datenbank. Zwischenzeitlich wird natürlich irgendwo unser ASP.NET-Code ausgeführt oder PHP-Code, aber alles eben in einer eigenen Thread Instanz. Irgendwann wird natürlich dann hier von Thread1 auch schon das fertige Ergebnis aus der Datenbank zurückgeliefert. Allerdings ist der Web-Server immer noch dann damit beschäftigt, erst mal den dritten Thread zu erzeugen, der dann auch wieder irgendwas macht. Zwischenzeitlich schafft er es dann wieder, bei dem allerersten Thread die Antwort an den Browser zurückschicken zu können, Dann macht der dritte Thread hier zum Beispiel irgendwas direkt auf dem Betriebssystem, zum Beispiel, dass er auf irgendwelche Daten lokal zugreift. Da kommen natürlich auch sofort die Antwort wieder zurück. Dann ist beim zweiten Thread schon mal so, dass die Daten aus der Datenbank bereit sind. Die können dann schon mal an den Client zurückgebracht werden. Der vierte Thread wird auch endlich mal erzeugt. Dieser greift auch wieder auf die Datenbank zu, und dann kann das Ergebnis auch wieder dann direkt zurückgebracht werden. Also man bemerkt schon, obwohl eben alles zur gleichen Zeit stattfindet, muss der Web-Server trotzdem die einzelnen Threads unterschiedlich priorisieren. Und die Zeit zum Erzeugen von Threads und zum Synchronisieren der Prozesse, das ist das, was eben viel Energie kostet für so einen Web-Server. Und wer selber schon mal Multithreading entwickelt hat, der weiß auch, dass es sich auch nur rentiert eine Parallelisierung oder mit Multithreading zu arbeiten, wenn die Verarbeitung länger andauert als dann später der tatsächliche Synchronisierungsvorgang benötigt wird, nur dann hat man wirklich einen Mehrwert gewonnen. Und das ist halt eben der Nachteil dieser klassischen Web-Server Architektur. Es wird extrem viel Energie dafür beansprucht, um Threads zu erzeugen, diese zu priorisieren, und das ist halt dann häufig der Nachteil. Der Vorteil ist natürlich auch wieder bei einem eigenen Thread, dass diese unabhängig von allen anderen Threads ausgeführt werden können. Sollte da irgendetwas schief laufen, dann wird nicht das ganze System deswegen kaputt gehen. Das ist natürlich auch ein Riesen-Vorteil. Als Beispiel, hätte ich jetzt in ASP.NET eine C-Sharp-Logik, die so einen komplexen Algorithmus hat, dass dieser Algorithmus zwei Minuten brauchen würde, dann ist nicht der ganze Web-Server blockiert, sondern dieser einzelne Thread, der wird halt einfach so lange im Hintergrund verarbeitet, bis er fertig ist. Das ist dann wieder der Vorteil, wenn das alles in einem eigenen Thread stattfindet. In diesem Video haben wir gesehen, wie die klassische Web-Server Architektur aufgebaut ist und dass diese eben alle durch eigene Threads behandelt werden.

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
Erscheinungsdatum:15.05.2017

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!