Apache vs. NGINX – Wer GEWINNT in Bezug auf die Leistung?

Apache vs NGINX ist eine der heißesten Debatten da draußen (seit der Veröffentlichung von NGINX), weil beide einer der häufigsten Webserver der Welt sind, gefolgt von LiteSpeed ​​und OpenLiteSpeed.

Apache und NGINX betreiben fast 60 % der weltweiten Websites. Apache und NGINX sind in Bezug auf Leistung und Funktionen ähnlich. Ihre Architektur, Sicherheit und Leistung sind dagegen alle unterschiedlich.

Es kann schwierig sein, zwischen diesen beiden Servern zu wählen, da sie beide ausgezeichnet sind. Da jeder Webserver seine eigenen Vor- und Nachteile hat, ist es wichtig, die bestmögliche Option zu wählen.

Sie können auch die Debatte zwischen Openlitespeed und Nginx hier überprüfen.

Vergleich der Geschwindigkeit zwischen Apache und NGINX

Bevor Sie tief in die Debatte zwischen Apache und NGINX eintauchen. Wir werden zuerst einen einfachen Geschwindigkeitstest durchführen, bei dem wir Tests in folgenden Szenarien durchführen werden.

• Lassen Sie uns eine kleine statische Datei von 5 KBytes testen
• Statische Datei mit einer Größe von 1 MB
• Testen einer einfachen PHP-Hello-World-Anwendung
• Benchmarking von Apache vs. NGINX für WordPress

Wir haben das gleiche Verfahren zum Testen von openlitespeed vs. nginx verwendet. OpenLiteSpeed ​​ist eine wirklich großartige Alternative zu NGINX, da es auch grundlegende .htaccess -Umschreibungsregeln unterstützt, sodass Sie problemlos von Apache zu OpenLiteSpeed ​​wechseln können.

Lassen Sie uns eine kleine statische Datei von 5 KBytes testen

Endgültiges Urteil : Beide Server haben mit einer kleinen statischen Datei die gleiche Leistung erbracht.

Apache

NGINX

Statische Datei mit einer Größe von 1 MB

Endgültiges Urteil : NGINX hat eindeutig mit einer großen statischen Datei gewonnen.

Apache

NGINX

Testen einer einfachen PHP-Hello-World-Anwendung

Endgültiges Urteil : Beide Server haben mit der PHP-Anwendung „Hello World“ die gleiche Leistung erbracht.

Apache

NGINX

Benchmarking von Apache vs. NGINX für WordPress

Endgültiges Urteil : NGINX hat eindeutig mit einer WordPress-Site gewonnen. Sie können diese Anleitung verwenden, um Ihren WooCommerce-Shop zu beschleunigen

Apache

NGINX

Testergebnis – Apache vs. NGINX

Wie wir in den Tests sehen können, ist NGINX in Bezug auf die Geschwindigkeit relativ besser als Apache. Die Ergebnisse sind:

1. Testen Sie eine kleine statische Datei von 5 KBytes:

In diesem Test sehen wir, dass sowohl Apache als auch NGINX relativ dieselben Ergebnisse liefern.

2. Testen Sie eine große statische Datei mit einer Größe von 1 MB:

In diesem Test sehen wir, dass die Geschwindigkeit von NGINX um Längen besser ist als die von Apache. NGINX gibt eine viel kürzere durchschnittliche Antwortzeit.

3. Testen Sie eine einfache PHP-Hello-World-Anwendung

In diesem Test sehen wir, dass sowohl Apache als auch NGINX relativ dieselben Ergebnisse liefern.

4. Test für Apache vs. NGINX für WordPress

In diesem Test sehen wir, dass die durchschnittliche Reaktionszeit von NGINX so viel kürzer ist als die von Apache, was ihm eine höhere Geschwindigkeit als die von NGINX verleiht.

Apache

Es gibt eine Gemeinschaft von Entwicklern, die Apache als Open-Source-Webserver pflegen. Es verwendet eine prozessgesteuerte Architektur, bei der für jede Verbindungsanforderung ein neuer Thread erstellt wird.
Darüber hinaus bietet Apache eine Vielzahl von Modulen, mit denen Sie die Funktionalität Ihres Webservers erweitern können. Apache ist schnell, zuverlässig, sicher und hochgradig anpassbar, um die Anforderungen verschiedener Umgebungen durch die Verwendung von Erweiterungen und Modulen zu erfüllen.

Verbindungsbehandlungsarchitektur

Apache verfügt über eine Reihe von Multi-Processing-Modulen (von Apache MPMs genannt), die steuern, wie Client-Anfragen verarbeitet werden. Im Wesentlichen ermöglicht dies Administratoren, die Architektur der Verbindungsbehandlung schnell auszutauschen.

• mpm-Prefor: Dieses Multi-Processing-Modul (MPM) implementiert einen Pre-Fork-Webserver, der keinen Thread hat. Jeder Serverprozess kann auf eingehende Anfragen antworten, und die Größe des Serverpools wird von einem übergeordneten Prozess verwaltet. Es eignet sich für Websites, die Threading vermeiden müssen, um mit Bibliotheken zu arbeiten, die nicht Thread-sicher sind. Es ist auch das beste MPM, um jede Anfrage zu isolieren und sicherzustellen, dass ein Problem mit einem keine Auswirkungen auf andere hat.
• mpm-worker: Ein hybrider Multiprozess-Multithread-Server wird durch dieses Multi-Processing-Modul (MPM) implementiert. Er kann eine große Anzahl von Anfragen mit weniger Systemressourcen bedienen als ein prozessbasierter Server, da er Threads verwendet, um Anfragen zuzustellen. Indem zahlreiche Prozesse mit jeweils vielen Threads verfügbar gehalten werden, behält er viel von der Stabilität eines prozessbasierten Servers.
• mpm-event: Das Ereignis Multi-Processing Module (MPM) soll ermöglichen, dass mehrere Anfragen gleichzeitig bedient werden, indem bestimmte Verarbeitungen an die Listener-Threads delegiert werden, wodurch die Worker-Threads frei werden, um neue Anfragen zu bedienen.
  Apache hat ein flexibles Design, das es Ihnen ermöglicht, aus einer Vielzahl von Verbindungs- und Anforderungsverarbeitungsalgorithmen auszuwählen. Da sich die Internetlandschaft verändert hat, sind die präsentierten Auswahlmöglichkeiten in erster Linie ein Produkt der Entwicklung des Servers und der gestiegenen Nachfrage nach Parallelität.

Statischer vs. dynamischer Inhalt

Statische Inhalte können von Apache-Servern mit ihren standardmäßigen dateibasierten Mechanismen verarbeitet werden. Für die Leistungsfähigkeit dieser Verfahren sind hauptsächlich die oben genannten MPM-Ansätze verantwortlich.

Apache kann zusätzlich dynamische Inhalte verarbeiten, indem es einen sprachspezifischen Prozessor in jede seiner Worker-Instanzen einbindet. Dadurch ist es möglich, dynamische Inhalte ohne die Verwendung externer Komponenten innerhalb des Webservers auszuführen. Dynamisch ladbare Module können verwendet werden, um diese dynamischen Prozessoren zu aktivieren.

Da Apache dynamische Inhalte intern verarbeiten kann, ist die Konfiguration der dynamischen Verarbeitung normalerweise einfacher. Module können bei geänderten inhaltlichen Anforderungen problemlos ausgetauscht werden und die Kommunikation muss nicht mit einer zusätzlichen Software koordiniert werden.

Verteilte vs. zentralisierte Konfiguration

Durch das Analysieren und Interpretieren von Direktiven in versteckten Dateien innerhalb der Inhaltsordner selbst fügt Apache eine Option hinzu, um eine weitere Konfiguration pro Verzeichnis zu ermöglichen. .htaccess Dateien sind der Name für diese Dateien.

Da sich diese Dateien in den Inhaltsordnern befinden, sucht Apache in jeder Komponente des Pfads zur angeforderten Datei nach einer .htaccess -Datei und wendet die dort gefundenen Anweisungen an. Dies ermöglicht effektiv eine dezentralisierte Webserver-Einrichtung, die häufig für URL-Umschreibungen, Zugriffsbeschränkungen, Autorisierung und Authentifizierung und sogar Cache-Richtlinien verwendet wird.

Während alle vorstehenden Beispiele in der Apache-Hauptkonfigurationsdatei eingerichtet werden können, bieten .htaccess -Dateien eine Reihe von Vorteilen. Da sie erstens jedes Mal ausgewertet werden, wenn sie entlang eines Anforderungspfads angetroffen werden, werden sie implementiert, ohne dass der Server neu geladen werden muss. Zweitens ermöglicht es nicht-privilegierten Benutzern, bestimmte Teile ihres eigenen Webinhalts zu steuern, ohne ihnen die vollständige Autorität über die Konfigurationsdatei zu geben.

Bestimmte Web-Software, wie z. B. Content-Management-Systeme, können jetzt ihre Umgebung einfach anpassen, ohne Zugriff auf die zentrale Konfigurationsdatei zu benötigen. Shared-Hosting-Anbieter nutzen dies, um die Kontrolle über das Kern-Setup zu behalten und gleichzeitig Kunden Zugriff auf ihre spezifischen Verzeichnisse zu bieten.

Datei vs. URI-basierte Interpretation

Apache kann eine Anfrage entweder als physische Dateisystemressource oder als URI-Ziel interpretieren, was eine abstraktere Bewertung erfordert. Im Allgemeinen verwendet Apache <Directory> - oder <File> -Blöcke für erstere, während <Location> -Blöcke für abstraktere Ressourcen verwendet werden.

Da Apache von Grund auf als Webserver konzipiert wurde, interpretiert er Anfragen standardmäßig als Dateisystemressourcen. Um eine tatsächliche Datei zu finden, beginnt es mit dem Dokumentenstamm und hängt den Teil der Anfrage nach der Host- und Portnummer an. Im Web wird die Dateisystemhierarchie im Wesentlichen durch den verfügbaren Dokumentenbaum repräsentiert.

Wenn die Anfrage nicht mit dem zugrunde liegenden Dateisystem übereinstimmt, bietet Apache eine Reihe von Optionen. Eine Alias-Direktive kann beispielsweise verwendet werden, um auf einen anderen Ort abzubilden. Durch die Verwendung von <Location> -Blöcken anstelle des Dateisystems können Sie direkt mit dem URI arbeiten. Es sind auch Variationen regulärer Ausdrücke verfügbar, um die Konfiguration flexibler auf das gesamte Dateisystem anzuwenden.

Obwohl Apache sowohl auf dem zugrunde liegenden Dateisystem als auch auf dem Webspace arbeiten kann, verwendet es lieber Dateisystemtechniken. Einige der Designentscheidungen spiegeln dies wider, beispielsweise die Verwendung von .htaccess-Dateien für die Einstellung pro Verzeichnis.

Modul

Das Modulsystem in Apache ermöglicht es Ihnen, Module dynamisch zu laden und zu entladen, um Ihre Anforderungen zu erfüllen, während der Server läuft. Der Apache-Kern ist immer vorhanden, aber Module können aktiviert oder deaktiviert, Funktionen hinzugefügt oder gelöscht und eine Verbindung zum Hauptserver hergestellt werden.

Diese Funktion wird von Apache für eine Vielzahl von Aufgaben verwendet. Aufgrund der Reife der Plattform wird sie mit einer großen Modulbibliothek geliefert. Mod php beispielsweise bettet einen PHP-Interpreter in jeden laufenden Worker ein und kann verwendet werden, um Teile der wesentlichen Funktionalität des Servers zu ändern.

Andererseits verarbeiten Module nicht nur dynamische Inhalte. Sie können unter anderem URLs umschreiben, Clients authentifizieren, den Server härten, protokollieren, zwischenspeichern, komprimieren, Proxys senden, die Rate einschränken und Daten verschlüsseln. Sie können erweiterte Funktionen bieten, ohne viel Arbeit hinzuzufügen.

Support, Kompatibilität, Ökosystem und Dokumentation

Da es Apache schon so lange gibt, gibt es viel Unterstützung dafür. Für den Kernserver und aufgabenbasierte Situationen, in denen Apache mit anderer Software verbunden wird, steht eine umfangreiche Bibliothek mit Dokumentationen von Erst- und Drittanbietern zur Verfügung.

Viele Tools und Webprojekte enthalten neben der Dokumentation Tools, mit denen sie sich innerhalb einer Apache-Umgebung selbst booten können. Dies kann in den Projekten selbst oder in den Paketen bereitgestellt werden, die das Paketierungsteam Ihrer Distribution verwaltet.

Aufgrund seines Marktanteils und der verfügbaren Zeit; Apache wird im Allgemeinen mehr Unterstützung von Drittprojekten erhalten. Administratoren haben auch eher mit Apache gearbeitet, nicht nur wegen seiner weit verbreiteten Verwendung, sondern auch, weil viele Leute ihre Karriere in Shared-Hosting-Umgebungen beginnen, wo Apache aufgrund der verteilten Verwaltungsfunktionen von .htaccess praktisch ausschließlich verwendet wird.

Vorteile von Apache gegenüber NGINX

Viele Webmaster und Entwickler bevorzugen Apache gegenüber NGINX, da es viel älter ist. Es ist mit Windows-, Unix- und Linux-Betriebssystemen kompatibel.

• Für die Ausgabe von dynamischem Material ist dies eine ausgezeichnete Leistung.
• Dynamisches Laden und Entladen von Modulen.
• Stellt eine .htaccess-Datei pro Verzeichnis bereit, die verwendet werden kann, um systemweite Einstellungen außer Kraft zu setzen.
• Support und Dokumentation sind hervorragend.
• Das Modell verwendet einen One-Connection-per-Process-Ansatz.
• Es enthält die Module mod_evasive und mod_security, die eine zusätzliche Sicherheitsebene hinzufügen.

Nachteile von Apache gegenüber NGINX

• Es ist nicht möglich, eine große Anzahl von Anfragen gleichzeitig zu bearbeiten.
• Im Vergleich zu NGINX dauert es länger, statische Inhalte anzuzeigen.
• Es bietet umfassende Einrichtungs- und Verwaltungsfunktionen. Aus diesem Grund ist es für Anfänger nicht geeignet.
• Websites mit viel Verkehr haben Leistungsprobleme.

NGINX

Um das „C10k“-Problem zu lösen, erfand der russische Programmierer Igor Sysoev NGINX. Igor hat sein Ziel erreicht: NGINX kann problemlos mehr als 10.000 gleichzeitige Verbindungen verwalten. Um neue Verbindungen besser handhaben zu können, hat NGINX ein ereignisgesteuertes und asynchrones Design. NGINX ist ein Webserver, der viele Funktionen bietet. Nachfolgend sind einige davon aufgeführt:

• Ein HTTP-Cache und ein Load Balancer
• Front-End-Proxy von Apache und anderen Webservern.
• HTTP-, HTTPS-, SMTP-, POP3- und IMAP-Protokolle werden alle von diesem Reverse-Proxy-Server bedient.

Seit seiner Veröffentlichung hat NGINX aufgrund seiner geringen Ressourcennutzung und der Fähigkeit, effektiv auf kostengünstiger Hardware zu skalieren, an Popularität gewonnen. NGINX ist ein Webserver, der sich darauf spezialisiert hat, statisches Material schnell bereitzustellen und darauf ausgelegt ist, dynamische Anfragen an Software weiterzuleiten, die für solche Aufgaben besser geeignet ist.

Verbindungsbehandlungsarchitektur

NGINX kam nach Apache auf den Markt, mit einem besseren Verständnis der Nebenläufigkeitsprobleme, mit denen Websites in großem Umfang konfrontiert werden würden. NGINX wurde von Grund auf mit einem asynchronen, nicht blockierenden, ereignisgesteuerten Verbindungsverarbeitungsalgorithmus entwickelt, um diese Informationen zu nutzen.

NGINX generiert Worker-Prozesse, von denen jeder Zehntausende von Verbindungen verarbeiten kann. Die Worker-Prozesse erreichen dies, indem sie einen schnellen Schleifenmechanismus entwickeln, der Ereignisse regelmäßig überprüft und verarbeitet. Durch die Entkopplung der tatsächlichen Arbeit von Verbindungen kann sich jeder Mitarbeiter nur dann auf eine Verbindung konzentrieren, wenn ein neues Ereignis aufgetreten ist.

Jede Verbindung des Arbeiters wird in die Ereignisschleife gestellt, wo sie mit anderen Verbindungen koexistiert. Ereignisse werden innerhalb der Schleife asynchron verarbeitet, sodass die Arbeit auf nicht blockierende Weise erledigt werden kann. Der Link wird nach dem Schließen aus der Schleife gelöscht.

NGINX kann dank seiner Verbindungsverarbeitungsmethode mit minimalen Ressourcen außergewöhnlich weit skalieren. Da der Server Single-Threaded ist und keine zusätzlichen Prozesse generiert werden, um jede neue Verbindung zu handhaben, bleiben die Speicher- und CPU-Auslastung relativ konstant, selbst wenn der Server stark ausgelastet ist.

Statischer vs. dynamischer Inhalt

NGINX bietet keine native Unterstützung für die dynamische Inhaltsverarbeitung. NGINX muss PHP- und andere Anforderungen für dynamische Inhalte zur Verarbeitung an einen externen Prozessor weiterleiten und dann auf die Rückgabe der gerenderten Inhalte warten. Der Kunde kann dann über die Ergebnisse informiert werden.

Für Administratoren bedeutet dies, dass die Kommunikation zwischen NGINX und dem Prozessor mit einem der Protokolle konfiguriert werden muss, die NGINX versteht (http, FastCGI, SCGI, uWSGI, Memcache). Dies kann die Dinge etwas komplizierter machen, insbesondere wenn die Anzahl der zuzulassenden Verbindungen geschätzt wird, da jeder Aufruf an den Prozessor eine neue Verbindung erfordert.

Andererseits bietet diese Strategie einige Vorteile. Der Overhead des dynamischen Interpreters wird nur für dynamisches Material vorhanden sein, da es nicht im Arbeitsprozess enthalten ist. Statische Inhalte können unkompliziert übermittelt werden, wobei der Dolmetscher nur bei Bedarf hinzugezogen wird. Dies ist auch mit Apache möglich, aber es eliminiert die im vorherigen Abschnitt erwähnten Vorteile.

Verteilte vs. zentralisierte Konfiguration

NGINX versteht keine .htaccess -Dateien und hat keine Möglichkeit, die Konfiguration pro Verzeichnis außerhalb der Hauptkonfigurationsdatei auszuwerten. Obwohl weniger vielseitig als der Apache-Ansatz, hat er seine eigenen Vorteile.

Die gesteigerte Leistung ist der deutlichste Vorteil gegenüber dem .htaccess -Ansatz der Einstellung auf Verzeichnisebene. Bei jeder Anfrage sucht der Server nach diesen Dateien in jedem der übergeordneten Verzeichnisse, die zur angeforderten Datei in einem Standard-Apache-Setup führen, das .htaccess in jedem Verzeichnis zulässt. Ergibt diese Suche eine oder mehrere .htaccess -Dateien, müssen diese gelesen und verarbeitet werden. NGINX kann Anfragen schneller bedienen, indem für jede Anfrage eine einzelne Verzeichnisabfrage und ein Dateilesen ausgeführt werden, indem Verzeichnisüberschreibungen nicht zugelassen werden (vorausgesetzt, die Datei befindet sich in der herkömmlichen Verzeichnisstruktur).

Ein weiterer Vorteil ist, dass es sicher ist. Durch das Verteilen des Konfigurationszugriffs auf Verzeichnisebene werden auch die Sicherheitsverantwortlichkeiten auf einzelne Benutzer verteilt, denen möglicherweise vertraut wird oder nicht, ob sie dies ordnungsgemäß tun. Indem Sie sicherstellen, dass der Administrator die vollständige Kontrolle über den Webserver hat, können Sie mehrere Sicherheitsfehler vermeiden, die auftreten können, wenn anderen Zugriff gewährt wird.

Wenn Sie sich über diese Probleme Sorgen machen, denken Sie daran, dass Sie die .htaccess Interpretation in Apache deaktivieren können.

Datei vs. URI-basierte Interpretation

NGINX wurde entwickelt, um sowohl als Webserver als auch als Proxyserver zu fungieren. Es arbeitet weitgehend mit URIs und übersetzt bei Bedarf aufgrund der für diese beiden Jobs erforderlichen Architektur in das Dateisystem.

Dies zeigt sich in einigen Fällen an der Art und Weise, wie NGINX-Konfigurationsdateien erstellt und verarbeitet werden.
NGINX hat keine Möglichkeit, die Konfiguration für ein Dateisystemverzeichnis anzugeben, daher analysiert es den URI.

Die Server- und Standortblöcke sind beispielsweise die wichtigsten Konfigurationsblöcke für NGINX. Der Server-Block ist für die Interpretation des angeforderten Hosts zuständig, während die Location-Blöcke für den Abgleich von Teilen des URI nach Host und Port zuständig sind. Die Anfrage wird jetzt als URI und nicht mehr als Speicherort im Dateisystem verarbeitet.

Alle Anfragen nach statischen Dateien müssen schließlich einem Ort auf der Disc zugeordnet werden. NGINX wählt zuerst die Server- und Standortblöcke aus, die die Anfrage verarbeiten, und kombiniert dann den Dokumentenstamm mit dem URI, wobei er je nach Bedarf basierend auf den Einstellungen modifiziert wird.

Dies mag ähnlich erscheinen, aber die Interpretation von Anfragen weitgehend als URIs und nicht als Dateisystemspeicherorte macht es für NGINX einfacher, als Web-, Mail- und Proxy-Server zu dienen. NGINX wird eingerichtet, indem definiert wird, wie es auf bestimmte Anfragemuster reagieren soll. NGINX inspiziert das Dateisystem erst, wenn es bereit ist, die Anfrage zuzustellen, weshalb .htaccess Dateien nicht unterstützt werden.

Module

NGINX hat ebenfalls ein Modulsystem, unterscheidet sich jedoch erheblich von dem von Apache. Module in NGINX können nicht dynamisch geladen werden, daher müssen sie ausgewählt und in die Kernsoftware kompiliert werden.
NGINX wird dadurch für viele Benutzer weitaus weniger anpassungsfähig. Dies gilt insbesondere für Benutzer, die zögern, ihre selbst erstellte Software außerhalb des Standardpaketierungsschemas ihrer Distribution zu pflegen. Während die Pakete der meisten Distributionen die am häufigsten verwendeten Module enthalten, müssen Sie den Server selbst aus den Quellen erstellen, wenn Sie ein nicht standardmäßiges Modul benötigen.

NGINX-Module hingegen sind immer noch sehr wertvoll, da sie es Ihnen ermöglichen, genau anzugeben, was Sie von Ihrem Server erwarten, indem Sie nur die Funktionen einbeziehen, die Sie verwenden möchten. Einige Benutzer glauben möglicherweise auch, dass dieser Ansatz sicherer ist, da keine beliebigen Komponenten mit dem Server verbunden werden können. Wenn Ihr Server jemals in eine Situation gebracht wird, in der dies denkbar ist, ist er mit ziemlicher Sicherheit bereits kompromittiert.

Viele der gleichen Funktionen sind in NGINX-Modulen verfügbar wie in Apache-Modulen. Proxy-Unterstützung, Komprimierung, Ratenbeschränkung, Protokollierung, Umschreiben, Geolokalisierung, Authentifizierung, Verschlüsselung, Streaming und E-Mail-Funktionen sind alle über NGINX-Module verfügbar.

Support, Kompatibilität, Ökosystem und Dokumentation

NGINX wird immer beliebter, da es aufgrund seiner hohen Leistung von immer mehr Menschen verwendet wird, aber es hat in bestimmten entscheidenden Bereichen noch Nachholbedarf.

Da der größte Teil der frühen Entwicklung und Dokumentation auf Russisch war, war es in der Vergangenheit schwierig, umfangreiche englischsprachige Dokumentation für NGINX zu finden. Die Dokumentation wurde vervollständigt, da das Interesse an dem Projekt gewachsen ist, und es stehen derzeit viele Verwaltungsressourcen auf der NGINX-Website und über Drittanbieter zur Verfügung.

Support und Dokumentation für Apps von Drittanbietern werden immer breiter verfügbar, und Paketbetreuer beginnen, unter bestimmten Umständen Optionen für die automatische Konfiguration von Apache und NGINX anzubieten. Die Konfiguration von NGINX für den Betrieb mit anderer Software ist normalerweise auch ohne Support einfach, solange die Anforderungen des Projekts dokumentiert sind (Berechtigungen, Header usw.).

Vorteile von NGINX

Der NGINX-Webserver ist einfach, leicht und schnell. Speziell für stark frequentierte Websites entwickelt.

• Verwendet eine ereignisgesteuerte, nicht blockierende Architektur, die weniger CPU und Arbeitsspeicher benötigt.
• Es enthält viele Optimierungs- und Bereitstellungsoptionen für statische Inhalte. Infolgedessen stellt es statische Inhalte 2,5-mal schneller bereit und verbraucht weniger Speicher als Apache.
• Es funktioniert bewundernswert in einem Multi-Prozessor-System.
• DDoS-Angriffe werden durch eine integrierte Konfigurationsoption verhindert.

Nachteile von NGINX

• Dynamische Inhalte können nicht nativ verarbeitet werden.
• Eine kleinere Anzahl von Modulen ist verfügbar.
• Linux- und Unix-Betriebssysteme werden unterstützt, Windows-Unterstützung ist jedoch eingeschränkt.
• Die von Apache unterstützte .htaccess -Datei wird von NGINX nicht unterstützt.
• Ein Mangel an Protokollüberwachungssoftware – Speichert Protokolle einfach in Dateien, die manuell durchsucht werden müssen.

So verwenden Sie Apache und NGINX zusammen

Nachdem Sie die Vor- und Nachteile von Apache und NGINX überprüft haben, sollten Sie in der Lage sein, festzustellen, welcher Server für Ihre Anforderungen besser geeignet ist. Viele Benutzer stellen jedoch fest, dass die gemeinsame Verwendung beider Server es ihnen ermöglicht, die Vorteile jedes Servers zu nutzen.

Die Standardkonfiguration für diese Zusammenarbeit ist die Verwendung von NGINX als Reverse-Proxy vor Apache. Dadurch kann NGINX alle Client-Anfragen verarbeiten. Dies nutzt die schnelle Verarbeitungsgeschwindigkeit von NGINX und die Fähigkeit, eine große Anzahl von Verbindungen gleichzeitig zu verwalten.

Die Dateien werden schnell und direkt an den Client für statische Inhalte geliefert, was NGINX auszeichnet. NGINX leitet Anfragen für dynamische Inhalte wie PHP-Skripte an Apache weiter, der die Ergebnisse verarbeitet und die gerenderte Seite bereitstellt. Das Material kann dann über NGINX an den Kunden zurückgesendet werden.

Für viele Benutzer funktioniert dieses Design gut, da es NGINX ermöglicht, als Sortiermaschine zu fungieren. Es wird alle Anfragen bearbeiten, die es bearbeiten kann, und diejenigen weiterleiten, die es nicht bearbeiten kann. Wir können einen Teil der Blockierung reduzieren, die auftritt, wenn ein Apache-Prozess oder -Thread belegt ist, indem wir die Anzahl der Anfragen reduzieren, die der Apache-Server verarbeiten soll.

Sie können mit dieser Anordnung skalieren, indem Sie nach Bedarf weitere Back-End-Server hinzufügen. NGINX kann einfach so eingerichtet werden, dass Anfragen an einen Pool von Servern weitergeleitet werden, wodurch die Fehlertoleranz und Leistung der Konfiguration verbessert wird.

Wann sollte Apache vs. NGINX verwendet werden?

Sowohl Apache als auch NGINX, wie in diesem Artikel beschrieben, sind leistungsstarke, anpassungsfähige und rundum gute Webserver. Für stark frequentierte Websites eignet sich Apache am besten für die Bereitstellung von dynamischem Material, während NGINX am besten für die Bereitstellung von statischen Inhalten oder Medienströmen geeignet ist. So einfach ist es:

Wann können Sie Apache verwenden

• Wenn Sie einen Shared-Hosting-Plan haben.
• Wenn Sie eine hilfreiche Community mit einer Vielzahl von Ressourcen schätzen, sind Sie hier genau richtig.
• Apache ist bei Webentwicklern beliebt, weil es einfach einzurichten ist.

Wann können Sie NGINX verwenden

• Wenn Sie einen VPS oder dedizierten Server haben.
• Sie sind der Besitzer einer beliebten Website mit vielen statischen Inhalten.
• Wenn Sie den eingehenden Datenverkehr verwalten und an langsamere Upstream-Server verteilen möchten.

Apache vs. NGINX: Welchen sollten Sie 2022 für Ihren Server wählen?

Je nachdem, welches Ihr Hosting-Unternehmen bereitstellt, sollten Sie es verwenden. In vielen Fällen haben Sie keine Option. Viele Webanbieter verfolgen die gleiche Strategie, der Sie folgen sollten, wenn Sie sich zwischen Apache vs. NGINX entscheiden:

• Apache ist eine gute Wahl, wenn Sie einen Server hosten möchten, der ständig eingerichtet werden muss, oder wenn Sie Benutzern eine Konfigurationsoption geben möchten.
• NGINX hingegen ist der richtige Weg, wenn Sie superschnelle Leistung, felsenfeste Sicherheit und die Möglichkeit wünschen, Konfigurationen statt Ihrer Benutzer zu verwalten.

Aufgrund seiner grundlegenden Architektur kann Apache leistungsmäßig mehr RAM beanspruchen. In Fällen mit hohem Datenverkehr wird NGINX besser abschneiden, insbesondere wenn viel statisches Material zu verwalten ist.

NGINX ist daher möglicherweise die ideale Lösung, wenn Sie auf Caching zum Speichern und Bereitstellen von Inhalten angewiesen sind. Denken Sie daran, dass NGINX kein dynamisches Material bereitstellen kann; Daher wird Ihre Leistung von der Effektivität des Proxys beeinflusst, den Ihr Server verwendet.

Fazit

Wie Sie sehen können, sind sowohl Apache als auch NGINX leistungsstark, anpassungsfähig und leistungsfähig. Die Bewertung Ihrer individuellen Bedürfnisse und das Testen der Muster, die Sie erwarten, sind die Hauptkriterien für die Auswahl des richtigen Servers für Sie.

Zwischen diesen Projekten gibt es erhebliche Unterschiede in der Rohleistung, den Fähigkeiten und der Zeit, die für die jeweilige Implementierung benötigt wird. Oft sind sie jedoch das Ergebnis einer Reihe von Kompromissen, die nicht ignoriert werden sollten. Zu guter Letzt gibt es keinen One-Size-Fits-All-Webserver, also wählen Sie die Option, die Ihren Bedürfnissen entspricht.