Warum ist Nginx schneller als Apache?
Lassen Sie uns über ein paar Konzepte im Allgemeinen sprechen:
1: Nginx ist bei hoher Parallelität schneller als Apache, und niedrige Parallelität ist nicht offensichtlich
2: Der Grund, warum es schnell ist, liegt im Epoll-Modell von Nginx.
Apache ist Multithread oder Multiprozess. Wenn beim Arbeiten eine http-Antwort eintrifft, Ein Prozess empfängt es (Listen) –>Identifikationsverarbeitung –>Rückgabeanforderung, während dieses Prozesses verarbeitet ein Prozess alles, Apche liest oder schreibt für Socket-E/A, aber Lesen oder Schreiben sind blockiert, was bedeutet, dass der Prozess blockiert werden muss Sobald viele Verbindungen vorhanden sind, generiert Apache zwangsläufig mehr Prozesse, um auf die Anforderung zu reagieren. Sobald viele Prozesse vorhanden sind, wechselt die CPU häufig, was Ressourcen und Zeit verbraucht, was zu Apache führt Die Leistung ist gesunken, um es ganz klar auszudrücken: Es kann nicht mehr so viele Prozesse verarbeiten.
Nginx übernimmt das Epoll-Modell, das asynchron und nicht blockierend ist. Für Nginx ist die vollständige Verarbeitung einer Verbindungsanforderung in Ereignisse unterteilt, jeweils ein Ereignis. Zum Beispiel „accept()“, „receive()“, „Disk I/O“, „send()“ usw. Jeder Teil verfügt über ein entsprechendes Modul, das verarbeitet werden muss. Eine vollständige Anfrage kann von Hunderten von Modulen verarbeitet werden. Der eigentliche Kern ist das Ereigniserfassungs- und -verteilungsmodul, das den Kern für die Verwaltung aller Module darstellt.
Nur die Planung von Kernmodulen kann es den entsprechenden Modulen ermöglichen, CPU-Ressourcen zu belegen, um Anforderungen zu verarbeiten. Nehmen Sie als Beispiel eine HTTP-Anfrage, registrieren Sie das gewünschte Listening-Ereignis und kehren Sie dann direkt zurück, ohne es zu blockieren eine Verbindung kommt (epoll ist an der Reihe) und die CPU kann andere Dinge erledigen.
Sobald eine Anfrage eingeht, wird der entsprechende Kontext der gesamten Anfrage zugewiesen (tatsächlich wurde er im Voraus zugewiesen). Zu diesem Zeitpunkt werden neue Ereignisse von Interesse (Lesefunktion) registriert Wenn die Client-Daten eingehen, wird der Prozess automatisch darüber informiert, dass es Zeit ist, die Daten zu lesen. Nach dem Parsen werden die Daten auf der Festplatte gespeichert (I/O). /O ist abgeschlossen, der Prozess wird benachrichtigt und der Prozess beginnt, Daten an den Client zurückzusenden (send()). Warten Sie nach dem Aufruf einfach, bis der Kernel das Benachrichtigungsergebnis zurücksendet.
Die gesamte Anfrage ist in viele Phasen unterteilt. Jede Phase wird bei vielen Modulen registriert und dann verarbeitet, die alle asynchron und nicht blockierend sind. Asynchron bedeutet hier, etwas zu tun, ohne auf die Rückgabe des Ergebnisses zu warten. Sie werden automatisch benachrichtigt, wenn es erledigt ist.
Ich habe ein Beispiel im Internet gefunden:
Ein einfaches Beispiel kann den Arbeitsablauf von Apache veranschaulichen. Normalerweise gehen wir zum Essen in ein Restaurant. Das Arbeitsmodell des Restaurants besteht darin, dass ein Kellner den Kunden ständig bedient. Der Kellner wartet an der Tür auf den Gast und begrüßt den gedeckten Tisch. wartet auf die Bestellung des Kunden (Request-URI) und geht in die Küche, um den Koch anzurufen (Disk-I/O), wartet, bis die Küche fertig ist (Read), und serviert dann die Gerichte die Gäste (senden). Der Kellner (Prozess) ist vielerorts blockiert.
Auf diese Weise kann das Restaurant bei mehr Gästen (mehr HTTP-Anfragen) nur mehr Kellner zum Bedienen rufen (Fork-Prozess), aber da die Ressourcen des Restaurants begrenzt sind (CPU), sind es auch einmal Bei vielen Kellnern entstehen sehr hohe Verwaltungskosten (CPU-Kontextwechsel), wodurch ein Engpass entsteht.
Mal sehen, wie Nginx damit umgeht? Hängen Sie eine Türklingel an die Tür des Restaurants (registrieren Sie das Abhören des Epoll-Modells). Sobald ein Gast eintrifft (HTTP-Anfrage), wird ein Kellner geschickt, um ihn zu empfangen (annehmen). Danach erledigt der Kellner andere Dinge (). (z. B. wieder Gäste empfangen) und wartet auf diesen Gast. Nachdem der Gast das Essen bestellt hat, ruft er den Kellner an (die Daten kommen in read() an. Der Kellner kommt und bringt die Speisekarte in die Küche (Disk-I/O). Wenn die Küche fertig ist, ruft er den Kellner an (Disk-I/O-Ende), der Kellner serviert den Gästen das Geschirr (send()), die Küche serviert ein Gericht an die Gäste, nachdem es fertig ist, und die Kellner können in der Zwischenzeit andere Dinge erledigen.
Der gesamte Prozess ist in viele Phasen unterteilt, und jede Phase verfügt über entsprechende Servicemodule. Denken wir darüber nach, damit das Restaurant bei mehr Gästen auch mehr Menschen aufnehmen kann.
Weitere technische Artikel zu Nginx finden Sie in der Spalte Tutorial zur Nginx-Nutzung!
Das obige ist der detaillierte Inhalt vonWarum Nginx schneller ist als Apache. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!