Wie ist Nginx auf Leistung und Skalierbarkeit ausgelegt?

NGINX zeichnet sich durch sein einzigartiges Design in Netzwerkanwendungen aus. Viele Netzwerk- oder Anwendungsserver sind meist einfache Frameworks, die auf Threads oder Prozessen basieren. Das Besondere an NGINX ist sein ausgereiftes ereignisgesteuertes Framework, das Tausende gleichzeitiger Verbindungen auf moderner Hardware verarbeiten kann.
Die interne Infografik von NGINX beginnt auf der obersten Ebene des Prozess-Frameworks und arbeitet sich nach unten, um zu zeigen, wie NGINX mehrere Verbindungen in einem einzigen Prozess verarbeitet, und untersucht weiter, wie es funktioniert.
Szenarioeinstellung – NGINX-Prozessmodell

Um dieses Entwurfsmuster besser zu verstehen, müssen wir verstehen, wie NGINX funktioniert. NGINX verfügt über einen Hauptthread, der privilegierte Vorgänge wie das Lesen von Konfigurationsdateien und das Binden von Ports sowie eine Reihe von Arbeitsprozessen und Hilfsprozessen abwickelt.

# service nginx restart

* Nginx wird neu gestartet

# ps -ef --forest |

root 32475 1 0 13:36 ? 00:00:00 nginx: Masterprozess /usr/sbin/nginx

-c /etc/nginx/nginx.conf

nginx 32476 32475 0 13:36 ? 00:00:00 _ nginx: Worker-Prozess

nginx 32477 32475 0 13:36 ? 00:00:00 _ nginx: Worker-Prozess

nginx 32479 32475 0 13:36 ? 00:00:00 _ nginx: Worker-Prozess

nginx 32480 32475 0 13:36 ? 00:00:00 _ nginx: Worker-Prozess

nginx 32481 32475 0 13: 36 ? 00:00:00 _ nginx: Cache-Manager-Prozess

nginx 32482 32475 0 13:36 ? 00:00:00 _ nginx: Cache-Loader-Prozess

In diesem Quad-Core-Server erstellt der Hauptthread vier Arbeitsprozesse und eine Reihe von Cache-Hilfsprozessen, die zur Verwaltung des Festplatten-Cache verwendet werden.
Warum ist der Rahmen so wichtig?
Die Basis jeder Unix-Anwendung ist ein Thread oder Prozess – beim Linux-Betriebssystem sind Threads und Prozesse fast gleich; ist, dass der Speicher zwischen Threads geteilt wird. Ein Thread oder Prozess ist ein eigenständiger Satz von Anweisungen, deren Ausführung das Betriebssystem auf einem einzelnen CPU-Kern plant. Viele komplexe Anwendungen laufen aus zwei Gründen parallel auf mehreren Threads oder Prozessen:

Anwendungen können mehrere CPU-Kerne des Computers gleichzeitig nutzen

Threads und Prozesse lassen sich einfach parallel betreiben, wie die gleichzeitige Verarbeitung mehrerer Verbindungen

Prozesse und Threads verbrauchen Ressourcen wie Speicher und andere Betriebssystemressourcen, Kernwechsel (ein- und ausgeschaltet). Kerne) ) (Dieser Vorgang wird als Kontextwechsel bezeichnet). Heutige Server müssen Tausende kleiner, aktiver Threads oder Prozesse gleichzeitig verarbeiten. Sobald der Speicher erschöpft ist oder die Lese- und Schreiblast zu hoch ist, kommt es zu umfangreichen Kontextwechseln und die Leistung wird erheblich beeinträchtigt.
Die übliche Designidee besteht darin, dass Netzwerkanwendungen jeder Verbindung einen Thread oder Prozess zuweisen. Diese Art von Framework ist einfach und leicht zu implementieren, aber schwierig zu skalieren, wenn Tausende von Verbindungen gleichzeitig verarbeitet werden.
Wie funktioniert NGINX?
NGINX nutzt ein prädiktives Prozessmodell, um verfügbare Hardwareressourcen zu planen:

Der Hauptprozess verarbeitet privilegierte Vorgänge wie das Lesen von Konfigurationsdateien, Portbindung usw. sowie die Erstellung einer kleinen Gruppe von Unterprozessen (die nächsten drei Arten von Prozessen)

Cache wird beim Start geladen. Der Serverprozess lädt den Cache von der Festplatte in den Speicher und wird dann beendet. Die Planung ist konservativ, sodass der Ressourcenaufwand gering ist

Der Cache-Verwaltungsprozess wird regelmäßig ausgeführt und bereinigt Entitäten aus dem Festplatten-Cache auf die angegebene Größe

Der Worker-Prozess ist für alle Arbeiten verantwortlich und verwaltet Netzwerkverbindungen, Lese- und Schreibvorgänge auf der Festplatte sowie die Upstream-Serverkommunikation.

Die empfohlene Konfiguration von NGINX lautet: Ein Worker-Prozess entspricht einem CPU-Kern, um eine effektive Nutzung der Hardware-Ressourcen sicherzustellen. Stellen Sie worker_processes auto in der Konfigurationsdatei ein:

worker_processes auto;

Sobald NGINX mit der Bereitstellung beginnt, ist nur der Arbeitsprozess beschäftigt, und jeder Arbeitsprozess verarbeitet mehrere Verbindungen auf nicht blockierende Weise, wodurch die Anzahl der Kontextwechsel reduziert wird.
Jeder Arbeitsprozess ist Single-Threaded und wird unabhängig ausgeführt. Er ist für den Erwerb neuer Verbindungen und deren Verarbeitung verantwortlich. Prozesse kommunizieren über gemeinsam genutzten Speicher, z. B. Cache-Daten, Sitzungspersistenzdaten und andere gemeinsam genutzte Ressourcen. NGINX 1.7.11 und spätere Versionen verfügen über einen optionalen Thread-Pool, an den Worker-Prozesse blockierende Vorgänge werfen. Weitere Einzelheiten finden Sie unter „Nginx führt Thread-Pool ein, um die Leistung um das Neunfache zu verbessern“. Für NGINX Plus-Benutzer werden diese neuen Funktionen dieses Jahr in Release 7 erscheinen.
NGINX interner Arbeitsprozess

Jeder NGINX-Arbeitsprozess wird durch eine Konfigurationsdatei initialisiert und der Hauptprozess stellt ihm eine Reihe von Listening-Sockets zur Verfügung.
Der Arbeitsprozess beginnt mit Socket-Listening-Ereignissen (accept_mutex und Kernel-Socket-Sharding). Die Ereignisse werden durch neue Verbindungen initialisiert und diese Verbindungen werden dann an eine Zustandsmaschine weitergeleitet. Die HTTP-Zustandsmaschine ist die am häufigsten verwendete, aber NGINX implementiert auch Stream-basierte Zustandsmaschinen und Kommunikationsprotokoll-basierte Zustandsmaschinen (SMTP, IMAP und POP3).

Die Zustandsmaschine ist ein wichtiger Befehlssatz, der NGINX mitteilt, wie jede Anfrage verarbeitet werden soll . Viele Webserver verfügen über die gleiche Funktionalität wie die Zustandsmaschine von NGINX – der Unterschied liegt in ihrer Implementierung.
Planungszustandsmaschine
Die Zustandsmaschine ist wie folgt Unter Chess ist eine einzelne HTTP-Transaktion wie eine Schachpartie. Auf der einen Seite des Schachbretts befindet sich der Webserver – wie ein Großmeister, der sehr schnell Entscheidungen trifft, und auf der anderen Seite der Remote-Client – ​​ein Webbrowser, der über ein relativ langsames Netzwerk auf eine Website oder Anwendung zugreift.
Die Spielregeln können jedoch sehr komplex sein. Beispielsweise muss der Netzwerkdienst möglicherweise mit einem Dritten oder einem Authentifizierungsserver oder sogar einem Drittanbieter kommunizieren. Party-Modul im Server zur Erweiterung der Spielregeln.
Blockierungszustandsmaschine
Zurück zur vorherigen Beschreibung, Prozess bzw Threads sind eine Reihe von Anweisungen, deren Ausführung das Betriebssystem auf einem bestimmten CPU-Kern plant. Die meisten Webserver und Webanwendungen spielen das Schachspiel nach dem Modell eines Prozesses, der eine Verbindung verarbeitet, oder eines Threads, der eine Verbindung verwaltet, wobei jeder Prozess oder Thread, der Anweisungen enthält, am gesamten Spiel teilnimmt. Während dieser Zeit ist der auf dem Server laufende Prozess die meiste Zeit blockiert, d. h. er wartet darauf, dass ein Client den nächsten Schritt abschließt.

Der Netzwerkserverprozess wartet auf neue Verbindungen am Socket . Diese neuen Verbindungen zum Spiel werden vom Client initiiert.

Sobald Sie ein neues Spiel erhalten und die Spielsitzung betreten, müssen Sie jedes Mal warten, bis der Client antwortet, und der Vorgang wird blockiert.

Sobald das Spiel beendet ist, prüft der Netzwerkserverprozess, ob der Client erneut spielen möchte (entsprechend einer Live-Verbindung). Sobald die Verbindung geschlossen wird (der Client verlässt die Verbindung oder es kommt zu einer Zeitüberschreitung), kehrt der Netzwerkserverprozess zum Warten auf neue Spiele zurück.

Denken Sie daran, dass jede aktive HTTP-Verbindung, also jedes Schachspiel, einen bestimmten Prozess oder Thread wie einen Schachmeister erfordert, um daran teilzunehmen. Diese Architektur ist einfach und lässt sich leicht um Modelle von Drittanbietern oder neue Regeln erweitern. Allerdings liegt hier eine äußerst unausgewogene Logik vor, die durch einen einzelnen Dateideskriptor und eine kleine Speichermenge dargestellt wird. Diese Verbindung wird einem Thread oder Prozess zugeordnet, und der Thread oder Prozess ist eine Gewichtungsebene Betriebssystemobjekte. Obwohl es beim Programmieren praktisch ist, ist die Verschwendung enorm.
NGINX ist ein echter Meister
Vielleicht du ich Ich habe von gleichzeitig gezeigten Partien gehört, bei denen ein Schachmeister gleichzeitig gegen zwölf Spieler spielt.

Der NGINX-Worker-Prozess spielt auch so „Schach“, jeder Worker-Prozess - ein A Arbeiter auf einem CPU-Kern – ein Meister, der Tausende von Spielen gleichzeitig bewältigen kann.

Der Worker-Prozess stellt eine Verbindung her und beginnt, den Socket abzuhören, um die zu erhalten Ereignis dort;

Sobald der Socket das Ereignis empfängt, verarbeitet der Worker-Prozess das Ereignis sofort:

• Ein Listening-Ereignis am Socket bedeutet, dass der Client ein neues Schachspiel startet und der Arbeitsprozess eine neue Socket-Verbindung erstellt.

• Ein Ereignis bei der Socket-Verbindung besteht darin, dass der Client eine Bewegung ausführt und der Arbeitsthread entsprechend reagiert.

Der Arbeitsprozess blockiert niemals die Netzwerkübertragung und wartet auf die Antwort seines Gegenstücks (Client). Nach jedem Zug verarbeitet der Worker-Prozess schnell andere wartende Schachpartien oder heißt neue Spieler willkommen.
Warum ist es schneller als blockierende Multiprozess-Frameworks?
Die gute Skalierbarkeit von NGINX besteht darin, dass es einen Arbeitsthread für die Verarbeitung Tausender Verbindungen unterstützt. Jede neue Verbindung erstellt einen Dateideskriptor, der nur wenig zusätzlichen Speicher im Arbeitsprozess verbraucht und der zusätzliche Overhead sehr gering ist. Prozesse können immer an CPUs angeheftet werden, daher sind Kontextwechsel relativ selten und erfolgen nur, wenn keine Arbeit anfällt. Anmerkung des Übersetzers: CPU-Bindung bezieht sich auf die Bindung eines oder mehrerer Prozesse an einen oder mehrere Prozessoren
Blockierungsmethode verwendenDas heißt, eine Verbindung entspricht Ein Prozess, jede Verbindung erfordert viele zusätzliche Ressourcen und Overhead, und der Kontextwechsel kommt sehr häufig vor.
(Weitere Einzelheiten finden Sie im Artikel von Andrew Alexeev über die NGINX-Architektur. Der Autor ist NGINX-Mitbegründer und Vizepräsident für Unternehmensentwicklung.)
Solange das System richtig abgestimmt ist, kann jeder Worker-Prozess von NGINX Tausende von gleichzeitigen HTTP-Verbindungen verarbeiten und Netzwerkspitzen problemlos bewältigen, d. h. es können mehr Schachpartien gleichzeitig gespielt werden Zeit.
Konfigurationsdateien aktualisieren, um NGINX zu aktualisieren
Das Prozess-Framework verfügt über eine kleine Anzahl von Arbeitsprozessen, was die Konfiguration erleichtert Datei- und sogar Binärdateiaktualisierungen.

Das Aktualisieren der NGINX-Konfiguration ist ein einfacher, leichter und zuverlässiger Vorgang. Das heißt, solange Sie den Befehl nginx -s reload ausführen, wird die Konfigurationsdatei auf der Festplatte überprüft und ein SIGHUB-Signal an den Hauptprozess gesendet.
Sobald der Hauptprozess einen SIGHUB erhält, führt er zwei Dinge aus:

Laden Sie die Konfigurationsdatei neu, erstellen Sie einen neuen Satz von Arbeitsprozessen, und die neu erstellten Arbeitsprozesse akzeptieren sofort Verbindungen und wickeln die Netzwerkkommunikation ab (übernehmen der neuen Konfigurationsumgebung).

Benachrichtigt alte Worker-Prozesse zur ordnungsgemäßen Einführung und diese Worker-Prozesse akzeptieren keine neuen Verbindungen mehr. Sobald die aktuell verarbeitete HTTP-Anfrage abgeschlossen ist, schließt der Arbeitsprozess die Verbindung. Sobald alle Verbindungen geschlossen sind, wird der Arbeitsprozess beendet.

Das Neuladen des Prozesses führt zu einer kleinen CPU- und Speicherspitze, aber der Overhead ist im Vergleich zum Laden von Ressourcen über eine aktive Verbindung minimal. Konfigurationsdateien können mehrmals pro Sekunde neu geladen werden. NGINX-Workerprozesse, die viele wartende Verbindungen zum Schließen generieren, verursachen im Allgemeinen selten Probleme, aber selbst wenn es Probleme gibt, können diese schnell gelöst werden.
Das NGINX-Binärdatei-Upgrade erreicht eine hervorragende Hochverfügbarkeit – Sie können Dateien online ohne Verbindungsverlust, Dienstausfall oder Dienstunterbrechung aktualisieren. Anmerkung des Übersetzers: Die Arbeit kann im Handumdrehen erledigt werden, während das Programm läuft.

Der Binärdatei-Upgrade-Prozess ähnelt dem eleganten Neuladen der Konfigurationsdatei; der neue NGINX-Hauptprozess läuft parallel zum ursprünglichen Hauptprozess und teilt den Listening-Socket. Beide Prozesse sind aktiv und wickeln ihre jeweilige Netzwerkkommunikation ab. Sie können den ursprünglichen Hauptprozess und seine Arbeitsprozesse benachrichtigen, damit sie ordnungsgemäß beendet werden.
Eine detaillierte Beschreibung des Prozesses finden Sie unter NGINX Control
Abschließende Schlussfolgerung
Die interne Infografik von NGINX zeigt einen Panoramablick auf die hochwertigen Funktionen von NGINX. Hinter der einfachen Erklärung steckt seit mehr als zehn Jahren kontinuierliche Innovation und Optimierung welches NGINX weit verbreitet ist und an verschiedene Hardwareplattformen angepasst ist und die beste Leistung erzielt. Selbst in der heutigen Zeit müssen Netzwerkanwendungen Sicherheit und Zuverlässigkeit gewährleisten, und NGINX leistet eine außergewöhnlich gute Leistung.
Wenn Sie mehr über die NGINX-Optimierung erfahren möchten, finden Sie hier einige gute Informationen:

NGINX-Installation und Leistungsoptimierung

NGINX-Leistungsoptimierung

《Nginx führt einen Thread-Pool ein, um die Leistung um das Neunfache zu verbessern 》

NGINX - Open Source Application Framework

NGINX Socket Sharding Release 1.9.1

Nachdruck von : Python-Entwickler

Das Obige stellt vor, wie Nginx auf Leistung und Skalierbarkeit ausgelegt ist. Ich hoffe, dass es Freunden, die sich für PHP-Tutorials interessieren, hilfreich sein wird, einschließlich relevanter Inhalte.