Warum sollte ich einen Prozess mit Threads / Prozessen anstelle eines asynchronen Webservers wählen?

Das ist alt, aber es lohnt sich zu antworten. Lassen Sie uns zunächst sagen, wie jedes Modell funktioniert.

In Threading haben Sie eine Anforderung an einen Handler, der Handler erzeugt einen neuen Betriebssystem-Thread, um diese Anfrage zu bearbeiten, und alle Aufgaben für diese Anfrage werden in diesem Thread ausgeführt, bis eine Antwort gesendet und der Thread beendet wird. Dieses Modell unterstützt so viele gleichzeitige Anfragen wie Threads, die Ihr Server spawnen kann (aber Threads können etwas schwergewichtig sein).

Beim Ausführen von async kommt eine Anfrage in einen Handler, aber anstatt einen Thread zu erstellen, der damit umgehen soll, fügt sie die Verbindung zu einer so genannten Ereignisschleife hinzu. Die Ereignisschleife überwacht Daten / Statusänderungen auf der Verbindung und löst jedes Mal Callbacks aus, wenn "etwas" passiert. Sobald die Verbindung zur Ereignisschleife hinzugefügt wurde, wartet der Handler sofort auf neue Verbindungen, die hinzugefügt werden sollen. Auf diese Weise können Sie viele (manchmal 100 K) gleichzeitige Verbindungen gleichzeitig haben .

  

Gibt es irgendwelche Features / Technologien, die ich nicht mit einer asynchronen Methode verwenden kann (oder würde schlecht / nicht so gut funktionieren)?

Ja, wenn Sie Zahlenverarbeitung betreiben. Die Architektur eines asynchronen (oder "evented") Systems ist derart, dass es großartig ist, Daten um herum zu übertragen, aber nicht Daten zu verarbeiten . Es kann Tausende von gleichzeitigen Operationen verarbeiten, da es jedoch nur auf einem OS-Thread ausgeführt wird, müssen die von ihm ausgelösten Rückrufe so wenig wie möglich ausgeführt werden, um den höchsten Durchsatz zu erzielen. Dies liegt daran, dass wenn einer Ihrer Callbacks einige Zahlen verarbeitet, die 5 Sekunden dauern, Ihr gesamter Server für 5 Sekunden eingefroren wird , bis dieser Vorgang abgeschlossen ist. Die Idee besteht darin, Daten zu erhalten, sie an den Zielort zu senden (Datenbank, API usw.) und eine Antwort mit minimaler Verarbeitung zu senden.

Async ist gut für Netzwerk-I / O: Daten zwischen mehreren Quellen / Zielen (und auch Benutzeroberflächen, aber das geht über diesen Post hinaus).

  

Welche Situationen führen dazu, dass die Leistung einer asynchronen Methode schlechter abschneidet als eine thread / prozessbasierte Methode? Sind diese häufigen oder seltenen Fälle, und wie groß ist der Unterschied?

Siehe oben. Wenn Sie jedoch mehr CPU-Arbeit als Netzwerk-E / A ausführen, sollten Sie zu einem Threading-Modell wechseln. Es gibt jedoch Workarounds für die Architektur ... Sie können beispielsweise eine Async-App verwenden und zu jeder Zeit, an der echte Arbeit erforderlich ist, einen Job an eine Worker-Warteschlange senden. Wenn jedoch für jede Anfrage eine CPU-Verarbeitung erforderlich ist, ist diese Architektur übertrieben und Sie können auch einfach einen Thread-Server verwenden.

  

Gibt es noch andere Faktoren, die ich beim Vergleich der beiden berücksichtigen sollte? Denken Sie daran, ich konzentriere mich hauptsächlich auf die Thread / Prozess-basierte Methode vs. asynchrone, keine bestimmte Server-Software, die zufällig eine dieser Methoden verwendet. Diese Bedenken können Schwierigkeiten bei der Verwaltung / Fehlersuche, Sicherheitsprobleme usw. sein.

Die Programmierung in async ist generell komplizierter als Threading. Das heißt, wenn Sie nicht selbst programmieren (dh Sie entscheiden sich zwischen Nginx und Apache), dann empfehle ich Ihnen normalerweise, async (nginx) zu gehen, weil Sie in der Regel mehr Saft aus Ihrem Server auf diese Weise drücken können . Ich bin immer dafür, möglichst viel Async im Stapel zu verwenden.

Wenn Sie eine App programmieren und versuchen, ein Threading- oder Async-Modell zu verwenden, müssen Sie die Entwicklerzeit berücksichtigen. Wenn du nicht eine Sprache verwendest, die grüne Fäden über einer Ereignisschleife hat (wie ein Schema), dann solltest du dir ziemlich viele Haare zerreißen, wenn deine ganze App abstürzt und du deinen Kopf herumwirfst CPS / Callbacks für alles verwenden. Futures / Versprechen sind dein Freund, aber sind nur ein Bandaid, um Asynchroner zu machen.

TL; DR

Async kann, wenn es in einem Server verwendet wird, mehr gleichzeitige Operationen durchführen als Threading , wenn Sie Netzwerk-IO und sonst nichts tun .

Wenn Sie irgendeine Art von Zahlenverarbeitung durchführen, verwenden Sie entweder einen App-Server mit Threads oder verwenden Sie eine asynchrone App mit einem Hintergrund-Queuing-System.

Async ist viel schwieriger zu programmieren, es sei denn, Ihre Sprache unterstützt "falsches" Threading darüber (dh grüne Threads). Sobald Sie über den anfänglichen Buckel hinauskommen, geht es Ihnen im Allgemeinen gut. Wenn Sie keine grünen Fäden haben, verwenden Sie Versprechen.

Wenn Sie die Wahl zwischen threaded und async als Komponente in Ihrem Stack haben (apache vs nginx), und sie die exakt gleichen Funktionen bereitstellen, bevorzugen Sie leicht async. Wählen Sie nicht nur, weil Sie denken, dass es alles 20x schneller machen wird.

Prozesse haben gegenüber Threads und asynchronen Modellen in Bezug auf Sicherheit und Zuverlässigkeit einige Vorteile. Die meisten Websites benötigen diese besonderen Vorteile nicht, aber manchmal sind sie unverzichtbar.

1. Sicherheit: Sie können Ihre Arbeitsprozesse in einer Sandbox als Benutzer mit niedriger Berechtigung ausführen und nur eine Anforderung pro Arbeitsprozess verarbeiten. Dadurch werden einige Sicherheitslücken geschlossen: Auch wenn ein Angreifer den gesamten Worker-Prozess übernimmt, solange Sie ihn basierend auf den Metadaten der Anfrage eng miteinander verknüpfen (dh er hat keinen Schreibzugriff auf alle Ihre Daten), dann kann er t die Systemstabilität beeinträchtigen oder die Antworten auf Anfragen beeinflussen.
2. Sicherheit # 2: Manchmal müssen Sie nicht vertrauenswürdigen Code in der Sandbox platzieren oder die Trennung zwischen verschiedenen Codes oder unterschiedlichen Anforderungen erzwingen, und die einzige Möglichkeit dafür besteht in einem separaten One-Shot-Prozess. (Denken Sie daran, den vom Benutzer bereitgestellten Code auszuführen.)
3. Zuverlässigkeit: Speicherverluste und Speicherbeschädigungen sind viel weniger gravierend, wenn Sie Arbeitsprozesse regelmäßig (oder für jede Anforderung) abbauen und ersetzen.
4. Es ist einfach, harte Grenzen für CPU-Zeit, Festplatten- und Netzwerkkontingente usw. zu erzwingen, die für die Verarbeitung einer Benutzeranforderung in einem separaten Prozess aufgewendet werden müssen. Selbst wenn der Anforderungsbehandlungscode in eine Endlosschleife übergeht, kann der Masterprozess (oder das Betriebssystem) eine Zeitüberschreitung erzwingen.