Warum ist Nginx so schnell?

Wir alle wissen, dass Nginx für seine hohe Leistung, Stabilität, umfangreiche Funktionen, einfache Konfiguration und geringen Ressourcenverbrauch bekannt ist. Warum ist Nginx also so schnell? Lassen Sie es uns anhand der zugrunde liegenden Prinzipien analysieren.

Nginx-Prozessmodell

Nginx-Server im Normalbetrieb:

Mehrere Prozesse: ein Master-Prozess und mehrere Worker-Prozesse.

Master-Prozess: verwaltet den Worker-Prozess.

Externe Schnittstelle: Empfangen externer Vorgänge (Signale);

Interne Weiterleitung: Verwalten von Arbeitern anhand verschiedener externer Vorgänge;

Überwachung: Überwachen Sie den laufenden Status des Worker-Prozesses und starten Sie ihn automatisch neu, nachdem der Worker-Prozess abnormal beendet wurde Verfahren.

Worker-Prozess: Alle Worker-Prozesse sind gleich.

Tatsächliche Verarbeitung: Netzwerkanfragen, verarbeitet vom Worker-Prozess.

Anzahl der Worker-Prozesse: In nginx.conf konfiguriert, im Allgemeinen auf die Anzahl der Kerne eingestellt, um die CPU-Ressourcen voll auszunutzen. Vermeiden Sie gleichzeitig eine übermäßige Anzahl von Prozessen, vermeiden Sie Prozesse, die um CPU-Ressourcen konkurrieren, und erhöhen Sie den Verlust des Kontextwechsels.

Denken:

Die Anfrage ist mit Nginx verbunden und der Master-Prozess ist für die Verarbeitung und Weiterleitung verantwortlich?

Wie wähle ich aus, welcher Worker-Prozess die Anfrage bearbeiten soll?

Muss das Ergebnis der Anforderungsverarbeitung noch den Master-Prozess durchlaufen?

HTTP-Verbindungsaufbau und Anforderungsverarbeitungsprozess sind wie folgt:

Wenn Nginx startet, lädt der Master-Prozess die Konfigurationsdatei. Master-Prozess, initialisiert den Listening-Socket. Master-Prozess, mehrere Worker-Prozesse ausgliedern. Worker-Prozesse konkurrieren um neue Verbindungen. Der Gewinner stellt durch einen Drei-Wege-Handshake eine Socket-Verbindung her und verarbeitet die Anfrage.

Nginx hohe Leistung, hohe Parallelität

Warum hat Nginx eine hohe Leistung und kann hohe Parallelität unterstützen?

Nginx verwendet eine Multiprozess- und asynchrone, nicht blockierende Methode (IO-Multiplexing Epoll). Der vollständige Prozess der Anfrage: Herstellen einer Verbindung → Lesen der Anfrage → Analysieren der Anfrage → Verarbeiten der Anfrage → Antworten auf die Anfrage. Der vollständige Prozess der Anfrage entspricht der untersten Ebene: dem Lesen und Schreiben von Socket-Ereignissen.

Nginx-Ereignisverarbeitungsmodell

Anfrage: HTTP-Anfrage in Nginx.

Grundlegender Arbeitsmodus des HTTP-Webservers:

Anfrage empfangen: Zeile für Zeile die Anforderungszeile und den Anforderungsheader lesen und den Anforderungstext lesen, nachdem festgestellt wurde, dass das Segment einen Anforderungstext hat. Bearbeiten Sie die Anfrage. Antwort zurückgeben: Generieren Sie basierend auf den Verarbeitungsergebnissen die entsprechende HTTP-Anfrage (Antwortzeile, Antwortheader, Antworttext).

Nginx folgt ebenfalls dieser Routine, und der Gesamtprozess ist der gleiche:

Modulare Architektur

Nginx-Module können grundsätzlich entsprechend ihrer Funktion in die folgenden Typen unterteilt werden:

①Ereignismodul: erstellt ein Unabhängig Das Framework des Ereignisverarbeitungsmechanismus des Betriebssystems ermöglicht die Verarbeitung spezifischer Ereignisse. Einschließlich ngx_events_module, ngx_event_core_module und ngx_epoll_module usw.

Das von Nginx verwendete spezifische Ereignisverarbeitungsmodul hängt vom jeweiligen Betriebssystem und den Kompilierungsoptionen ab.

②Phasenhandler: Dieser Modultyp wird auch direkt als Handlermodul bezeichnet. Hauptsächlich verantwortlich für die Verarbeitung von Client-Anfragen und die Generierung von Inhalten, auf die geantwortet werden soll, z. B. das Modul ngx_http_static_module, das für die Verarbeitung statischer Client-Seitenanforderungen und die Vorbereitung entsprechender Festplattendateien für die Ausgabe von Antwortinhalten verantwortlich ist.

③Ausgabefilter: Auch als Filtermodul bekannt, ist es hauptsächlich für die Verarbeitung des Ausgabeinhalts verantwortlich und kann die Ausgabe ändern.

Sie können beispielsweise allen Ausgabe-HTML-Seiten eine vordefinierte Fußleiste hinzufügen oder die URL des Ausgabebilds ersetzen.

④Upstream: Das Upstream-Modul implementiert die Reverse-Proxy-Funktion, leitet die echte Anfrage an den Back-End-Server weiter, liest die Antwort vom Back-End-Server und sendet sie an den Client zurück.

Das Upstream-Modul ist eine besondere Art von Handler, mit der Ausnahme, dass der Antwortinhalt nicht von ihm selbst generiert, sondern vom Back-End-Server gelesen wird.

⑤Load-Balancer: Das Lastausgleichsmodul implementiert einen bestimmten Algorithmus und wählt einen Server unter vielen Back-End-Servern als Weiterleitungsserver für eine bestimmte Anfrage aus.

Analyse häufiger Probleme:

Nginx vs. Apache

Nginx:

IO-Multiplexing, Epoll (kqueue auf freebsd), hohe Leistung und hohe Parallelität, belegt weniger Systemressourcen

Apache:

Blockierung + Multiprozess/ Mehrere Threads sind stabiler, Fehler sind weniger, Module sind umfangreicher

Nginx maximale Anzahl von Verbindungen

Grundlegender Hintergrund:

Nginx ist ein Multiprozessmodell und der Worker-Prozess wird zum Verarbeiten von Anfragen verwendet. Die Anzahl der Verbindungen (Dateideskriptor fd) eines einzelnen Prozesses hat eine Obergrenze (nofile): ulimit -n. Konfigurieren Sie die maximale Anzahl von Verbindungen für einen einzelnen Worker-Prozess auf Nginx: Die Obergrenze von worker_connections ist nofile. Konfigurieren Sie die Anzahl der Worker-Prozesse auf Nginx: worker_processes.

Daher beträgt die maximale Anzahl von Verbindungen für Nginx:

Die maximale Anzahl von Verbindungen für Nginx: die Anzahl der Worker-Prozesse x die maximale Anzahl von Verbindungen für einen einzelnen Worker-Prozess. Das Obige ist die maximale Anzahl von Verbindungen, wenn Nginx als allgemeiner Server verwendet wird. Wenn Nginx als Reverse-Proxy-Server dient, beträgt die maximale Anzahl an Verbindungen, die es bedienen kann: (Anzahl der Worker-Prozesse x maximale Anzahl der Verbindungen für einen einzelnen Worker-Prozess) / 2. Wenn der Nginx-Reverse-Proxy verwendet wird, wird eine Verbindung zum Client und eine Verbindung zum Back-End-Webserver hergestellt, wobei zwei Verbindungen belegt werden.

Denken:

Jedes Mal, wenn ein Socket geöffnet wird, belegt er ein fd? Warum ist die Anzahl der FDS, die ein Prozess öffnen kann, begrenzt?

HTTP-Anfrage und -Antwort

HTTP-Anfrage:

Anfragezeile: Methode, URI, HTTP-Version, Anfrage-Header, Anfragetext

HTTP-Antwort:

Antwortzeile: http-Version, Statuscode, Antwort-Header, Antworttext

IO-Modell

Bei der Verarbeitung mehrerer Anfragen können Sie Folgendes verwenden: IO-Multiplexing oder blockierendes IO + Multithreading:

IO-Multiplexing: Ein Thread verfolgt mehrere Socket-Status, und derjenige, der bereit ist, wird gelesen und geschrieben. Blockierendes IO + Multithreading: Für jede Anfrage wird ein neuer Service-Thread erstellt.

Was sind die anwendbaren Szenarien für IO-Multiplexing und Multithreading?

IO-Multiplexing: Es gibt keinen Vorteil in der Anforderungsverarbeitungsgeschwindigkeit einer einzelnen Verbindung. Große Parallelität: Es wird nur ein Thread verwendet, um eine große Anzahl gleichzeitiger Anforderungen zu verarbeiten, wodurch der Verlust beim Kontextwechsel reduziert wird. Es besteht keine Notwendigkeit, Probleme mit der Parallelität zu berücksichtigen, und er kann relativ mehr Anforderungen verarbeiten. Verbraucht weniger Systemressourcen (kein Thread-Planungsaufwand erforderlich). Geeignet für lange Verbindungen (lange Verbindungen im Multithread-Modus können leicht zu zu vielen Threads und zu häufiger Planung führen). Blockierende E/A + Multithreading: einfach zu implementieren und nicht auf Systemaufrufen angewiesen. Jeder Thread benötigt Zeit und Platz. Wenn die Anzahl der Threads zunimmt, steigt der Aufwand für die Thread-Planung exponentiell.

select/poll und epoll werden wie folgt verglichen:

select/poll Systemaufruf:

// select 系统调用
int select(int maxfdp,fd_set *readfds,fd_set *writefds,fd_set *errorfds,struct timeval *timeout); 
// poll 系统调用
int poll(struct pollfd fds[], nfds_t nfds, int timeout)；

select:

Fragen Sie fd_set ab, um zu sehen, ob ein bereiter fd vorhanden ist Deskriptor) bereit. Oder nach einer Zeitüberschreitung zurückkehren. fd_set ist ein Bitsatz, die Größe ist eine Konstante beim Kompilieren des Kernels, die Standardgröße ist 1024. Merkmale: Die Anzahl der Verbindungen ist begrenzt, die Anzahl der fds, die fd_set darstellen kann, ist zu gering. Um festzustellen, ob fd bereit ist, müssen Sie eine Seite von fd_set durchlaufen Informationen zum Status der Verbindungsbereitschaft.

Umfrage:

Lösen Sie das Verbindungslimit: Ersetzen Sie in der Umfrage fd_set in select durch ein pollfd-Array, um das Problem einer zu kleinen Anzahl von fd zu lösen. Datenreplikation: Benutzerbereich und Kernelbereich, Informationen zum Verbindungsbereitschaftsstatus kopieren.

epoll, ereignisgesteuert:

Ereignismechanismus: Vermeiden Sie einen linearen Scan, registrieren Sie ein Abhörereignis für jeden FD. Wenn sich FD in „Bereit“ ändert, fügen Sie FD zur Bereitschaftsliste hinzu. Anzahl der FDS: Keine Begrenzung (Grenzwert auf Betriebssystemebene, wie viele FDS von einem einzelnen Prozess geöffnet werden können).

select, poll, epoll:

I/O-Multiplex-Mechanismus. Beim E/A-Multiplexing wird ein Mechanismus zur Überwachung mehrerer Deskriptoren verwendet (normalerweise Lese- oder Schreibbereitschaft), und das Programm kann entsprechende Lese- und Schreibvorgänge zur Überwachung mehrerer Deskriptoren durchführen. Aber Select, Poll und Epoll sind im Wesentlichen synchrone E/A: Der Benutzerprozess ist für das Lesen und Schreiben verantwortlich (das Kopieren vom Kernelraum in den Benutzerraum). Während des Lese- und Schreibvorgangs ist der Benutzerprozess nicht blockiert erfordern, dass der Benutzerprozess für das Lesen und Schreiben verantwortlich ist. Asynchrones E/A ist für das Kopieren vom Kernelraum in den Benutzerraum verantwortlich.

Die gleichzeitigen Verarbeitungsfunktionen von Nginx

Über die gleichzeitigen Verarbeitungsfunktionen von Nginx: Die Anzahl der gleichzeitigen Verbindungen, im Allgemeinen nach der Optimierung, kann der Spitzenwert bei etwa 1 bis 3 W gehalten werden. (Die Anzahl der Speicher- und CPU-Kerne ist unterschiedlich, es wird Raum für weitere Optimierungen geben)

Verwandte Empfehlungen: nginx-Tutorial

Das obige ist der detaillierte Inhalt vonWarum ist Nginx so schnell?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!