Warum Nginx besser ist als Apache

Nginx hat in nur wenigen Jahren den Großteil des Webservermarktes erobert. Wie wir alle wissen, ist Nginx bei der Verarbeitung großer gleichzeitiger statischer Anfragen wesentlich effizienter als Httpd und kann sogar das C10K-Problem problemlos lösen.

Bei vielen gleichzeitigen Verbindungen ist Nginx eine gute Alternative zum Apache-Server. Nginx kann auch als Layer-7-Load-Balancing-Server verwendet werden. Laut meinen Testergebnissen kann Nginx + PHP (FastCGI) mehr als 30.000 gleichzeitige Verbindungen verarbeiten, was dem Zehnfachen von Apache in derselben Umgebung entspricht.

Im Allgemeinen kann ein Server mit 4 GB Speicher + Apache (Prefork-Modus) nur 3.000 gleichzeitige Verbindungen verarbeiten, da diese mehr als 3 GB Speicher belegen und 1 GB Speicher für das System reserviert werden muss. Ich hatte einmal zwei Apache-Server. Da die MaxClients-Einstellung in der Konfigurationsdatei 4000 betrug, waren der Serverspeicher und der Swap-Speicher voll und stürzten ab, als die Anzahl gleichzeitiger Apache-Verbindungen 3800 erreichte.

Bei 30.000 gleichzeitigen Verbindungen verbraucht dieser Nginx + PHP (FastCGI)-Server 150 M Speicher ( 15M*10=150M ) für die 10 geöffneten Nginx-Prozesse und 1280 M Speicher ( 20M*64=1280M ) für die 64 geöffneten PHP-CGI-Prozesse. Zusammen mit dem vom System selbst verbrauchten Speicher beträgt der gesamte verbrauchte Speicher weniger als 2 GB. Wenn der Serverspeicher klein ist, können Sie einfach 25 PHP-CGI-Prozesse starten, sodass der von PHP-CGI verbrauchte Gesamtspeicher nur 500 MB beträgt.

Mit 30.000 gleichzeitigen Verbindungen sind PHP-Programme, die auf den Nginx+ PHP (FastCGI)-Server zugreifen, immer noch sehr schnell.

Warum ist Nginx bei der Handhabung hoher Parallelität besser als httpd? Beginnen wir mit den Arbeitsprinzipien und Arbeitsmodi der beiden Webserver.

1. Drei Arbeitsmodi von Apache

Wir alle wissen, dass Apache drei Arbeitsmodule hat: Prefork, Worker und Event.

• Prefork: Mehrere Prozesse. Auf jede Anforderung antwortet ein Prozess, und dieser Prozess verwendet den Auswahlmechanismus zur Benachrichtigung.
• Worker: Multithreading, ein Prozess kann mehrere Threads generieren, jeder Thread antwortet auf eine Anfrage, aber der Benachrichtigungsmechanismus wählt immer noch aus, kann aber weitere Anfragen annehmen. Ereignis: Basierend auf dem asynchronen E/A-Modell, einem Prozess oder Thread, wobei jeder Prozess oder Thread auf mehrere Benutzeranforderungen antwortet, wird dies ereignisgesteuert (d. h. Epoll-Mechanismus) implementiert.

1. Funktionsprinzip von Prefork

Wenn Sie nicht explizit ein MPM mit „--with-mpm“ angeben, ist prefork das Standard-MPM auf der Unix-Plattform. Die verwendete Methode des vorab gegabelten untergeordneten Prozesses ist auch das in Apache1.3 verwendete Modell.

Prefork selbst verwendet keine Threads. Version 2.0 verwendet sie, um die Kompatibilität mit Version 1.3 aufrechtzuerhalten. Andererseits verwendet Prefork separate untergeordnete Prozesse, um verschiedene Anforderungen zu verarbeiten, und die Prozesse sind voneinander unabhängig, was es auch zu einem der stabilsten MPMs macht.

2. Arbeitsprinzip des Arbeiters

Im Vergleich zu Prefork ist Worker ein brandneues MPM in Version 2.0, das ein Hybridmodell aus Multithreading und Multiprozess unterstützt. Da zur Verarbeitung Threads verwendet werden, können relativ viele Anfragen verarbeitet werden und der Overhead der Systemressourcen ist geringer als bei prozessbasierten Servern.

Der Worker verwendet jedoch auch mehrere Prozesse, und jeder Prozess generiert mehrere Threads, um die Stabilität des prozessbasierten Servers zu erreichen. Dieser MPM-Arbeitsmodus wird der Entwicklungstrend von Apache 2.0 sein.

3. Ereignisbasierte Funktionen

Ein Prozess antwortet auf mehrere Benutzeranforderungen und verwendet den Rückrufmechanismus, um den Socket wiederzuverwenden. Nachdem die Anforderung eingegangen ist, verarbeitet der Prozess die Anforderung nicht, sondern übergibt sie direkt zur Verarbeitung an andere Mechanismen und verwendet den Epoll-Mechanismus, um zu benachrichtigen, ob die Anforderung abgeschlossen ist. Bei diesem Prozess befindet sich der Prozess selbst immer im Leerlauf und kann weiterhin Benutzeranforderungen empfangen. Ein Prozess kann auf mehrere Benutzeranforderungen antworten. Unterstützt eine große Anzahl gleichzeitiger Verbindungen und verbraucht weniger Ressourcen.

2. So verbessern Sie die gleichzeitige Verbindungsverarbeitungsfunktion des Webservers

Es gibt mehrere Grundvoraussetzungen:

1. Threadbasiert, d. h. ein Prozess generiert mehrere Threads und jeder Thread antwortet auf jede Anfrage des Benutzers.

2. Ereignisbasiertes Modell, ein Prozess verarbeitet mehrere Anfragen und benachrichtigt den Benutzer über den Abschluss der Anfrage über den Epoll-Mechanismus.

3. Festplattenbasiertes AIO (Asynchronous I/O)

4. Unterstützt die mmap-Speicherzuordnung. Wenn ein herkömmlicher Webserver eine Seite eingibt, gibt er zuerst die Festplattenseite in den Kernel-Cache ein und kopiert dann eine Kopie aus dem Kernel-Cache auf den Webserver. Der mmap-Mechanismus dient dazu, den Kernel-Cache der Festplatte zuzuordnen, und der Webserver kann den Seiteninhalt direkt kopieren. Es ist nicht erforderlich, die Seiten zuerst auf der Festplatte in den Kernel-Cache zu importieren.

Tatsächlich unterstützt Nginx alle oben genannten Funktionen. Daher ist die Aussage auf der offiziellen Nginx-Website, dass Nginx 50.000 gleichzeitige Verbindungen unterstützt, begründet.

3. Die Vorzüge von Nginx

Traditionell verarbeiten Webdienste, die auf einer Prozess- oder Thread-Modellarchitektur basieren, gleichzeitige Verbindungsanforderungen über jeden Prozess oder jeden Thread, was zwangsläufig zu Blockierungen bei Netzwerk- und E/A-Vorgängen führt. Ein weiteres unvermeidliches Ergebnis ist eine geringe Speicher- oder CPU-Auslastung.

Das Generieren eines neuen Prozesses/Threads erfordert die vorherige Vorbereitung seiner Laufzeitumgebung. Dazu gehört die Zuweisung von Heap- und Stack-Speicher sowie die Erstellung eines neuen Ausführungskontexts dafür. Diese Vorgänge erfordern CPU-Auslastung und zu viele Prozesse/Threads führen zu Thread-Jitter oder häufigem Kontextwechsel, was die Systemleistung weiter verschlechtert.

Ein weiterer leistungsstarker Webserver/Webserver-Reverseproxy: Nginx. Der Schwerpunkt von Nginx liegt auf seiner hohen Leistung und der hochdichten Nutzung physischer Rechenressourcen, daher wird ein anderes Architekturmodell verwendet. Inspiriert von den fortschrittlichen „ereignisbasierten“ Verarbeitungsmechanismen im Design verschiedener Betriebssysteme verwendet Nginx eine modulare, ereignisgesteuerte, asynchrone, einfädige und nicht blockierende Architektur und macht umfassenden Gebrauch von Multiplexing- und Ereignisbenachrichtigungsmechanismen.

In Nginx werden Verbindungsanforderungen von einer kleinen Anzahl von Worker-Prozessen verarbeitet, die mithilfe eines effizienten Run-Loop-Mechanismus nur einen Thread enthalten, und jeder Worker kann Tausende gleichzeitige Verbindungen und Anforderungen parallel verarbeiten.

4. Wie Nginx funktioniert

Nginx führt bei Bedarf mehrere Prozesse gleichzeitig aus: einen Master-Prozess und mehrere Worker-Prozesse. Wenn Caching konfiguriert ist, gibt es auch Cache-Loader-Prozesse und Cache-Manager-Prozesse. Alle Prozesse enthalten nur einen Thread und die Kommunikation zwischen Prozessen wird hauptsächlich über den Mechanismus des „Shared Memory“ erreicht. Der Hauptprozess wird als Root ausgeführt, während Worker, Cache Loader und Cache-Manager alle als nicht privilegierte Benutzer ausgeführt werden sollten.

Bei hoher Verbindungsparallelität ist Nginx eine gute Alternative zum Apache-Server.

Nginx lässt sich sehr einfach installieren, die Konfigurationsdatei ist sehr übersichtlich (es unterstützt auch die Perl-Syntax) und der Server weist nur sehr wenige Fehler auf: Nginx lässt sich sehr einfach starten, kann fast rund um die Uhr ohne Unterbrechung laufen und muss nicht neu gestartet werden, selbst wenn es mehrere Monate lang läuft. Sie können die Softwareversion auch aktualisieren, ohne den Dienst zu unterbrechen.

5. Die Geburt von Nginx löst hauptsächlich das C10K-Problem

Abschließend analysieren wir aus der Perspektive des jeweils verwendeten Multiplex-IO-Modells:

1. Modell auswählen: (wird von Apache verwendet, aber aufgrund von Einschränkungen wie Modulen nicht oft verwendet);

Es gibt eine Höchstgrenze für die Anzahl der Dateideskriptoren, die ein einzelner Prozess überwachen kann.

Die von select () verwaltete Datenstruktur speichert eine große Anzahl von Dateideskriptoren. Mit zunehmender Anzahl von Dateideskriptoren steigt auch der durch das Kopieren des Adressraums zwischen Benutzermodus und Kernel verursachte Overhead linear an.

Aufgrund der Verzögerung der Netzwerkantwortzeit sind viele TCP-Verbindungen inaktiv. Durch den Aufruf von select () wird jedoch dennoch ein linearer Scan aller Sockets durchgeführt, was zu einem gewissen Overhead führt.

2. poll: poll ist eine Neuimplementierung von select durch Unix. Das einzige Problem, das es löst, ist, dass poll keine Beschränkung hinsichtlich der maximalen Anzahl von Dateideskriptoren hat.

3. Epoll-Modell: (von Nginx verwendet)

Epoll bietet zwei Vorteile, die die Leistung erheblich verbessern:

1) Basierend auf der ereignisbasierten Bereitschaftsbenachrichtigungsmethode, der select/poll-Methode, scannt der Kernel alle überwachten Dateideskriptoren erst, nachdem der Prozess eine bestimmte Methode aufgerufen hat, und das epoll-Ereignis registriert einen Dateideskriptor über epoll_ctl(). Sobald ein Dateideskriptor bereit ist, verwendet der Kernel einen Callback-ähnlichen Rückrufmechanismus, um den Dateideskriptor schnell zu aktivieren, und epoll_wait() wird benachrichtigt

2) Wenn Sie epoll_wait() einmal aufrufen, um einen fertigen Dateideskriptor abzurufen, wird nicht der eigentliche Deskriptor zurückgegeben, sondern ein Wert, der die Anzahl der fertigen Deskriptoren darstellt. Diese Werte werden in ein von epoll angegebenes Array übernommen, um nacheinander die entsprechende Anzahl von Dateideskriptoren abzurufen. Hier wird die Memory-Mapping-Technologie (mmap) verwendet, um den Mehraufwand beim Kopieren einer großen Anzahl von Dateideskriptoren zu vermeiden.

3) Natürlich hat epoll auch gewisse Einschränkungen. epoll ist nur in Linux 2.6 implementiert und auf anderen Plattformen nicht. Dies steht offensichtlich im Widerspruch zu hervorragenden plattformübergreifenden Servern wie Apache.

4) Einfach ausgedrückt ist Epoll eine aktualisierte Version von Select und es gibt keine maximale Begrenzung für die von einem einzelnen Prozess verwalteten Dateideskriptoren. Aber epoll ist nur auf der Linux-Plattform verfügbar. Als Cross-Plattform wird Apache nicht verwendet

Quelle: http://codebay.cn/post/8557.html

Damit ist dieser Artikel darüber, warum Nginx besser ist als Apache, abgeschlossen. Weitere Informationen zu Nginx vs. Apache finden Sie in den vorherigen Artikeln von 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!