NGINX vs. Apache: Die beliebtesten Open-Source-Webserver im Vergleich
Die erste Version des Apache HTTP Servers erschien 1995. Noch heute, mehr als 20 Jahre später, regiert die Software als Häuptling unter den Webservern – doch nicht ohne Konkurrenz. Vor allem der russische Webserver NGINX (Aussprache wie „Engine-X“), ebenfalls ein Open-Source-Projekt, macht Marktanteile gut – und das in rasender Geschwindigkeit. Besonders schmerzlich für die Apache Foundation: Die meisten Websites, die im Alexa-Ranking gut abschneiden, werden heute schon über NGINX ausgeliefert. Dies zeigt eine regelmäßig aktualisierte Statistik von W3Techs. Nicht nur russische Internetgrößen wie die Suchmaschinen Rambler und Yandex, der E-Mail-Service Mail.RU oder das soziale Netzwerk VK setzen auf den leichtgewichtigen Webserver; auch internationale Anbieter wie Dropbox, Netflix, WordPress und FastMail.com nutzen NGINX, um die Performance ihrer Services zu verbessern. Gehört der Apache HTTP Server damit bald zum alten Eisen?
Der Apache HTTP Server ist ein Software-Projekt, das unter der Schirmherrschaft der Apache Foundation vorangetrieben wird. Im ökonomischen Sprachgebrauch der Internetgemeinde wird der Name des Webservers in der Regel auf „Apache“ verkürzt. Auch wir folgen dieser Konvention: Ist im Folgenden von „Apache“ die Rede, ist stets die Software und nicht der Hersteller gemeint.
Die Herausforderung des Web 2.0
Owen Garrett, Head of Products bei Nginx, Inc., bezeichnet den Apache-Webserver in einem Blogartikel vom 9. Oktober 2015 als „Backbone“ („Wirbelsäule“) des Web 1.0 und hebt damit dessen Bedeutung für die Entwicklung des Internets um die Jahrtausendwende hervor. Der große Erfolg des Webservers sei vor allem auf die einfache Architektur der Software zurückzuführen. Diese jedoch beruhe auf Design-Entscheidungen, die sich an einem World Wide Web orientierten, das mit dem von heute nicht zu vergleichen ist. Vor 20 Jahren waren Webseiten wesentlich einfacher aufgebaut, Bandbreite war beschränkt und teuer, CPU-Rechenzeit hingegen vergleichsweise günstig.
Heute haben wir es mit einem World Wide Web der zweiten Generation zu tun, und dieses zeigt sich von einer gänzlich anderen Seite: Die Anzahl der User sowie der weltweite Webtraffic haben sich vervielfacht. Das Gleiche gilt für die durchschnittliche Größe der Webseiten im Netz und die Anzahl der Komponenten, die ein Webbrowser abfragen und rendern muss, um diese darstellen zu können. Ein wachsender Teil der Internetgemeinde ist von klein auf mit den Möglichkeiten des Web 2.0 aufgewachsen. Diese Nutzergruppe ist es nicht gewohnt, mehrere Sekunden oder gar Minuten auf den Download einer Webseite zu warten.
Diese Entwicklungen haben den Apache HTTP Server in den vergangenen Jahren immer wieder vor Herausforderungen gestellt. Owen Garrett macht dafür die prozessbasierte Architektur des Apache verantwortlich, die angesichts des rasant steigenden Traffic-Aufkommens nicht gut skaliert werden könne. Dieser Schwachpunkt war eine der Hauptmotivationen für die Entwicklung von NGINX im Jahr 2002, der mit einer eventgesteuerten Architektur gänzlich andere Wege einschlägt. NGINX geht auf den russischen Software-Entwickler Igor Sysoev zurück, der die Software, die gleichermaßen als Webserver, Reverse-Proxy und E-Mail-Proxy zum Einsatz kommt, speziell auf die Bedürfnisse der russischen Suchmaschine Rambler zugeschnitten hat.
Wir stellen beide Webserver in einem Vergleich gegenüber und gehen dabei auf architektonische Unterschiede, die Konfiguration, Erweiterungsmöglichkeiten sowie auf Kompatibilität, Dokumentation und Support ein.
Architektonische Unterschiede
Die Webserver Apache und NGINX setzen auf grundverschiedene Software-Architekturen. Unterschiedliche Konzepte finden sich in Bezug auf das Verbindungsmanagement, die Interpretation von Clientanfragen, den Umgang mit statischen und dynamischen Webinhalten sowie bei der Konfiguration.
Verbindungsmanagement
Die Open-Source-Webserver Apache und NGINX unterscheiden sich im Wesentlichen darin, wie sie mit eingehenden Clientanfragen (Requests) umgehen. Während dem Apache eine prozessbasierte Architektur zugrunde liegt, erfolgt das Verbindungsmanagement bei NGINX auf Grundlage eines eventgesteuerten Verarbeitungsalgorithmus. Dieser ermöglicht es, Requests ressourcensparend abzuarbeiten, selbst wenn diese aus einer Vielzahl von Verbindungen gleichzeitig eingehen. Dies wird – u. a. von den NGINX-Entwicklern – als großer Vorteil gegenüber dem Apache HTTP Server angeführt. Doch auch dieser bietet ab Version 2.4 die Möglichkeit, Events zu implementieren. Die Unterschiede liegen somit im Detail.
Der Apache-Webserver folgt einem Ansatz, bei dem jede Clientanfrage von einem separaten Prozess oder Thread bearbeitet wird. Dies ist bei Single-Threading – dem ursprünglichen Betriebsmodus des Apache HTTP Servers – früher oder später mit I/O-Blocking-Problemen verbunden: Prozesse, die Schreib- oder Leseoperationen erfordern, werden strikt nacheinander abgearbeitet. Ein nachfolgender Request verweilt solange in der Warteschleife, bis der vorhergehende beantwortet wurde. Umgehen lässt sich dies, indem mehre Single-Threading-Prozesse gleichzeitig gestartet werden – eine Strategie, die mit einem hohen Ressourcen-Verbrauch verbunden ist.
Alternativ kommen Multi-Threading-Mechanismen zum Einsatz. Im Gegensatz zum Single-Threading, bei dem in jedem Prozess lediglich ein Thread zur Verfügung steht, um Clientanfragen zu beantworten, bietet Multi-Threading die Möglichkeit, mehrere Threads in ein und demselben Prozess laufen zu lassen. Da Threads unter Linux weniger Ressourcen benötigen als Prozesse, bietet Multi-Threading die Möglichkeit, den großen Ressourcenbedarf der prozessgestützten Architektur des Apache HTTP Servers zu kompensieren.
Integrieren lassen sich Mechanismen zur parallelen Bearbeitung von Clientanfragen bei Apache durch eines von drei Multi-Processing-Modulen (MPMs): mpm_prefork, mpm_worker, mpm_event.
- mpm_prefork: Das Apache-Modul „Prefork“ bietet ein Multi-Prozess-Management auf Basis eines Single-Threading-Mechanismus. Das Modul erzeugt einen Elternprozess, der einen Vorrat an Kindprozessen zur Verfügung stellt. In jedem Kindprozess läuft ein Thread, der es ermöglicht, jeweils eine Clientanfrage zu beantworten. Solange mehr Single-Thread-Prozesse vorhanden sind, als Clientanfragen eingehen, werden die Requests gleichzeitig abgearbeitet.
Die Anzahl der verfügbaren Single-Threading-Prozesse wird mithilfe der Serverkonfigurationsoptionen „MinSpareServers“ und „MaxSpareServers“ definiert. Prefork birgt die oben erwähnten Performance-Nachteile des Single-Threadings. Von Vorteil ist jedoch die weitgehende Unabhängigkeit separater Prozesse: Geht eine Verbindung aufgrund eines fehlerhaften Prozesses verloren, wirkt sich dies in der Regel nicht auf die Verbindungen aus, die in anderen Prozessen bearbeitet werden.
- mpm_worker: Mit dem Modul „Worker“ stellt Apache Nutzern einen Multi-Threading-Mechanismus zur parallelen Bearbeitung von Clientanfragen zur Verfügung. Wie viele Threads pro Prozess gestartet werden können, lässt sich mithilfe der Serverkonfigurationsoption „ThreadsPerChild“ definieren. Das Modul sieht einen Thread pro TCP-Verbindung vor. Solange mehr Threads zur Verfügung stehen, als Clientanfragen eingehen, werden die Requests parallel abgearbeitet. Über unbeschäftigte Threads wacht der Elternprozess (httpd).
Nutzern stehen die Befehle „MinSpareThreads“ und „MaxSpareThreads“ zur Verfügung, um zu definieren, ab welcher Anzahl unbeschäftigter Threads neue Threads erzeugt bzw. laufende Threads aus dem Speicher entfernt werden. Das Worker-Modul hat einen wesentlich geringen Ressourcenbedarf als das Prefork-Modul. Da Verbindungen nicht in separaten Prozessen verarbeitet werden, kann sich ein fehlerhafter Thread jedoch auf den gesamten Multi-Threading-Prozess und damit auf alle Verbindungen, die in diesem bearbeitet werden, auswirken. Zudem ist Worker ebenso wie Prefork anfällig für Überlastungen durch sogenannte Keep-Alive-Verbindungen (s. u.).
- mpm_event: Seit Version 2.4 steht dem Apache HTTP Server mit Event ein drittes Multi-Processing-Modul für den Produktiveinsatz zur Verfügung. Dieses stellt eine Variante des Worker-Moduls dar, die für eine Lastverteilung zwischen den gestarteten Threads sorgt. Dazu kommt pro Multi-Threading-Prozess ein sogenannter Listener-Thread zum Einsatz, der eingehende Clientanfragen entgegennimmt und damit zusammenhängende Aufgaben auf Worker-Threads verteilt.
Das Event-Modul wurde entwickelt, um den Umgang mit sogenannten Keep-Alive-Verbindungen zu optimieren, also TCP-Verbindungen, die aufrecht gehalten werden, um die Übertragung weiterer Clientanfragen oder Serverantworten (Responses) zu ermöglichen. Kommt das klassische Worker-Modul zum Einsatz, halten Worker-Threads einmal aufgebaute Verbindungen in der Regel aufrecht und werden somit blockiert – selbst dann, wenn keine weiteren Anfragen eingehen. Dies kann bei einer hohen Anzahl von Keep-Alive-Verbindungen zu einer Überlastung des Servers führen. Das Event-Modul hingegen lagert die Aufrechterhaltung von Keep-Alive-Verbindungen an den unabhängigen Listener-Thread aus. Worker-Threads werden somit nicht blockiert und stehen für die Bearbeitung weiterer Anfragen zur Verfügung.
Folgende Grafik zeigt eine schematische Darstellung der prozessbasierten Architektur des Apache-Webservers unter Verwendung des Worker-Moduls:
Je nachdem, welches Modul Anwendung findet, löst Apache das Concurrency-Problem (auch „Nebenläufigkeit“, die gleichzeitige Beantwortung mehrerer Clientanfragen) entweder durch zusätzliche Prozesse oder Threads. Beide Lösungsstrategien gehen mit zusätzlichem Ressourcenaufwand einher. Dieser wird bei der Skalierung eines Apache Servers zum limitierenden Faktor.
Der enorme Ressourcenhunger des Ein-Prozess-pro-Verbindung-Ansatzes resultiert daraus, dass für jeden zusätzlichen Prozess eine eigene Laufzeitumgebung bereitgestellt werden muss. Diese erfordert die Zuweisung von CPU-Zeit und separatem Speicher. Zudem muss jedes Apache-Modul, das in einem Worker-Prozess zur Verfügung stehen soll, für jeden Prozess separat geladen werden. Threads hingegen teilen sich eine Ausführungsumgebung (das Programm) und den Adressraum im Speicher. Der Overhead zusätzlicher Threads ist dadurch erheblich geringer als der von Prozessen. Doch auch Multi-Threading ist rechenintensiv, wenn es zu Kontextwechseln (Context Switches) kommt.
Als Kontextwechsel bezeichnet man den Vorgang, bei dem ein System von einem Prozess bzw. Thread zu einem anderen umschaltet. Dazu muss der Kontext des beendeten Prozesses bzw. Threads gesichert und der des neuen erzeugt bzw. wiederhergestellt werden. Ein zeitintensiver administrativer Vorgang, bei dem CPU-Register sowie diverse Tabellen und Listen geladen und gesichert werden müssen.
Das Modul mpm_event hält einen Event-Mechanismus für den Apache HTTP Server bereit, der die Bearbeitung eingehender Verbindungen an einen Listener-Thread auslagert. Dieser ermöglicht es, nicht mehr benötigte Verbindungen (auch Keep-Alive-Verbindungen) zu beenden und so den Ressourcenverbrauch zu reduzieren. Nicht gelöst wird das Problem rechenintensiver Kontextwechsel, die entstehen, wenn der Listener-Thread Requests über die von ihm gehaltenen Verbindungen an separate Worker-Threads übergibt.
Die von Grund auf eventbasierte Architektur von NGINX hingegen realisiert Nebenläufigkeit, ohne dass für jede neue Verbindung ein zusätzlicher Prozess oder Thread benötigt wird. Ein einzelner NGINX-Prozess kann Tausende von HTTP-Verbindungen gleichzeitig verarbeiten. Realisiert wird dies durch einen Schleifenmechanismus, den sogenannten Event-Loop. Dieser ermöglicht es, Clientanfragen asynchron innerhalb eines Threads abzuarbeiten.
Theoretisch kommt NGINX bei der Verarbeitung von Verbindungen mit nur einem Single-Threading-Prozess aus. Um die Hardware optimal auszunutzen, wird der Webserver in der Regel jedoch mit einem Worker-Prozess pro Prozessorkern (CPU) der zugrundeliegenden Maschine gestartet.
Anders als der Apache-Webserver, bei dem sich die Anzahl der aktiven Prozesse bzw. Threads lediglich durch Minimal- und Maximalwerte eingrenzen lässt, bietet NGINX ein vorhersagbares Prozessmodell, das exakt auf die zugrundeliegende Hardware abstimmt wird. Dieses umfasst einen Master-Prozess, die Helferprozesse Cache-Loader und Cache-Manager sowie eine auf die Anzahl der Prozessorkerne abgestimmte und durch die Konfiguration exakt festgelegte Anzahl an Worker-Prozessen.
- Master-Prozess: Beim Master-Prozess handelt es sich um einen übergeordneten Prozess, der alle grundlegenden Operationen ausführt. Zu diesen gehören u. a. das Einlesen der Server-Konfiguration, die Portbindung sowie die Erstellung aller folgenden Prozesstypen.
- Helferprozesse: NGINX nutzt zwei Helferprozesse für das Cache-Management: Cache-Loader und Cache-Manager.
- Cache-Loader: Der Cache-Loader ist dafür verantwortlich, dass der festplattenbasierte Cache in den Arbeitsspeicher geladen wird.
- Cache-Manager: Aufgabe des Cache-Managers ist es, darauf zu achten, dass Einträge aus dem Festplatten-Cache die zuvor konfigurierte Größe aufweisen, und diese bei Bedarf zu beschneiden. Dieser Prozess wird periodisch aufgerufen.
- Worker-Prozess: Worker-Prozesse sind für die Bearbeitung von Verbindungen, für Schreib- und Lesezugriffe auf die Festplatte sowie für die Kommunikation mit Upstream-Servern (Server, die anderen Servern Dienste zur Verfügung stellen) verantwortlich. Es handelt sich somit um die einzigen Prozesse des NGINX-Prozess-Modells, die durchgängig aktiv sind.
Folgende Grafik zeigt eine schematische Darstellung des NGINX-Prozess-Modells:
Alle Worker-Prozesse, die vom NGINX-Master-Prozess im Rahmen der Konfiguration gestartet werden, teilen sich ein Set von Listener-Sockets (Kommunikationsendpunkte). Statt für jede eingehende Verbindung einen eigenen Prozess oder Thread zu starten, wird in jedem Worker-Prozess ein Event-Loop ausgeführt, der die asynchrone Bearbeitung mehrerer Tausend Verbindungen innerhalb eines Threads ermöglicht, ohne den Prozess zu blockieren. Dazu lauschen die Worker-Prozesse an den Listener-Sockets kontinuierlich auf Events, die durch eingehende Verbindungen ausgelöst werden, nehmen diese an und führen während der Bearbeitung von HTTP-Requests Lese- und Schreibprozesse am Socket aus.
Dabei stellt NGINX keine eigenen Mechanismen für die Verteilung von Verbindungen auf Worker-Prozesse zu Verfügung. Stattdessen kommen Kernel-Funktionen des Betriebssystems zum Einsatz. Schemata, wie eingehende Anfragen zu verarbeiten sind, werden durch separate Zustandsmaschinen (State Machines) für HTTP, raw TCP sowie SMTP, IMAP und POP3 bereitgestellt.
Ganz allgemein kann NGINX als Event-Handler bezeichnet werden, der vom Kernel Informationen über Events erhält und dem Betriebssystem sagt, wie die damit zusammenhängenden Aufgaben zu bearbeiten sind. Die asynchrone Bearbeitung von Aufgaben innerhalb des Event-Loops beruht auf Ereignisbenachrichtigungen, Rückruffunktionen (Callbacks) und Timern. Diese Mechanismen ermöglichen es, dass ein Worker-Prozess eine Operation nach der anderen ans Betriebssystem delegieren kann, ohne untätig auf das Ergebnis einer Operation oder die Antwort von Client-Programmen warten zu müssen. NGINX fungiert somit als Orchestrator für das Betriebssystem, welches das Lesen und Schreiben von Bytes übernimmt.
Diese Art des Verbindungsmanagements erzeugt lediglich einen minimalen Overhead für zusätzliche Verbindungen. Alles was benötigt wird, ist ein zusätzlicher File Descriptor (FD) und ein Minimum an zusätzlichem Arbeitsspeicher im Worker-Prozess. Rechenintensive Kontextwechsel hingegen treten lediglich dann auf, wenn innerhalb eines Event-Loops keine weiteren Events auftreten. Diese Effektivität bei der Bearbeitung von Anfragen über eine Vielzahl von Verbindungen prädestiniert NGINX als Lastverteiler für stark frequentierte Websites wie beispielsweise WordPress.com.
NGINX bietet mit der eventgestützten Architektur eine Alternative zum prozessbasierten Verbindungsmanagement des Apache HTTP Servers. Als Erklärung, warum NGINX bei Benchmark-Tests so gut abschneidet, reicht dieses Merkmal allein jedoch nicht aus. Denn auch Apache unterstützt seit Version 2.4 einen eventbasierten Verarbeitungsmechanismus für Clientanfragen. Achten Sie bei Webserver-Vergleichen wie Apache vs. NGINX daher stets darauf, mit welchen Modulen die Webserver im Test zum Einsatz kommen, wie die Webserver konfiguriert sind und welche Aufgaben bewältigt werden müssen.
Umgang mit statischen und dynamischen Webinhalten
Auch im Umgang mit dynamischen Webinhalten folgt NGINX einer anderen Strategie als der Apache HTTP Server.
Prinzipiell gilt: Um dynamische Webinhalte ausliefern zu können, muss ein Webserver auf einen Interpreter zurückgreifen, der in der Lage ist, eine dazu benötigte Programmiersprachen wie PHP, Perl, Python oder Ruby zu verarbeiten. Apache stellt dazu diverse Module wie mod_php, mod_perl, mod_python oder mod_ruby zur Verfügung, die es ermöglichen, den entsprechenden Interpreter direkt in den Webserver zu laden. Somit wird Apache selbst mit der Fähigkeit ausgestattet, dynamische Webinhalte, die mit der entsprechenden Programmiersprache erstellt wurden, zu verarbeiten. Funktionen für die Bereitstellung statischer Inhalte werden bereits durch die oben angesprochenen MPM-Module implementiert.
NGINX hingegen bietet lediglich Mechanismen, um statische Webinhalte auszuliefern. Die Bereitstellung dynamischer Inhalte wird an darauf spezialisierte Anwendungsserver ausgelagert. NGINX fungiert in diesem Fall lediglich als Proxy zwischen Client-Programm und Upsteam-Server. Die Kommunikation erfolgt über Protokolle wie HTTP, FastCGI, SCGI, uWSGI und Memcached. Als mögliche Anwendungsserver für die Auslieferung dynamischer Inhalte bieten sich WebSphere, JBoss oder Tomcat an. Doch auch der Apache HTTP Server kann zu diesem Zweck zum Einsatz kommen.
Beide Strategien beim Umgang mit statischen und dynamischen Inhalten sind mit Vor- und Nachteilen verbunden. Ein Modul wie mod_php ermöglicht dem Webserver, PHP-Code selbst auszuführen. Ein separater Anwendungsserver wird nicht benötigt. Das macht die Administration dynamischer Webseiten sehr bequem. Die Interpreter-Module für dynamische Programmiersprachen jedoch müssen separat in jeden Worker-Prozess geladen werden, der mit der Auslieferung des Contents betraut ist. Bei einer großen Anzahl von Worker-Prozessen geht dies mit einem deutlichen Overhead einher. Diesen Overhead reduziert NGINX, da der ausgelagerte Interpreter nur bei Bedarf hinzugezogen wird.
Während NGINX auf die Interaktion mit einem ausgelagerten Interpreter festgelegt ist, stehen Apache-Nutzern prinzipiell beide Strategien offen. Auch Apache kann einem Anwendungsserver vorgelagert werden, der die Interpretation dynamischer Webinhalte übernimmt. In der Regel wird dazu das Protokoll FastCGI verwende. Eine entsprechende Schnittstelle lässt sich mit dem Modul mod_proxy_fcgi laden.
Mit beiden Webservern in unserem Vergleich lassen sich dynamische Webseiten ausliefern. Doch während Apache Programmcode, der dabei zum Einsatz kommt, mithilfe von Modulen selbst interpretiert und ausführt, lagert NGINX diesen Arbeitsschritt an einen externen Anwendungsserver aus.
Interpretation von Clientanfragen
Um Anfragen von Client-Programmen (beispielsweise Webbrowsern oder E-Mail-Programmen) zufriedenstellend beantworten zu können, muss ein Server auf Grundlage des Requests ermitteln, welche Ressource angefordert wird und wo sich diese befindet.
Der Apache HTTP Server wurde als Webserver konzipiert. NGINX hingegen bietet sowohl Web- als auch Proxy-Server-Funktionen. Dieser Unterschied im Fokus spiegelt sich u. a. in der Art wieder, wie die jeweilige Software Clientanfragen interpretiert und Ressourcen auf dem Server zuordnet.
Auch der Apache HTTP Server lässt sich mithilfe des Moduls mod_proxy als Proxyserver einsetzen.
Apache HTTP Server und NGINX verfügen beide über Mechanismen, die es ermöglichen, eingehende Requests entweder als physische Ressourcen im Dateisystem oder als URIs (Uniform Resource Identifier) zu interpretieren. Doch während der Apache standardmäßig dateibasiert arbeitet, steht bei NGINX die URI-basierte Verarbeitung von Anfragen im Vordergrund.
Geht beim Apache HTTP Server eine Client-Anfrage ein, geht dieser standardmäßig davon aus, dass eine bestimmte Ressource aus dem Dateisystem des Servers abgerufen werden soll. Da Apache mittels VirtualHosts die Möglichkeit bietet, unterschiedliche Webinhalte auf ein und demselben Server unter unterschiedlichen Host-Namen, IP-Adressen oder Port-Nummern bereitzustellen, muss zunächst ermittelt werden, auf welchen VirtualHost sich der Request bezieht. Dazu gleicht der Webserver Host-Name, IP-Adresse und Port-Nummer am Anfang der Request-URI mit den in der Hauptkonfigurationsdatei httpd.conf definierten VirtualHosts ab.
Folgendes Codebeispiel zeigt eine Apache-Konfiguration, bei der die beiden Domains www.example.com und www.other-example.com unter derselben IP-Adresse betrieben werden:
NameVirtualHost *:80
<VirtualHost *:80>
ServerName www.example.com
ServerAlias example.com *.example.com
DocumentRoot /data/www/example
</VirtualHost>
<VirtualHost *:80>
ServerName www.other-example.com
DocumentRoot /data/www/other-example
</VirtualHost>Möchten Sie mehr über Apache erfahren? Mehr Informationen finden Sie in unserem Beitrag zum Thema "Was ist Apache?".
Der Asterisk (*) dient als Platzhalter für eine beliebige IP-Adresse. In welcher DocumentRoot (dem Startverzeichnis eines Webprojekts) die angefragte Ressource gesucht wird, entscheidet Apache durch einen Abgleich des im Request enthaltenen Host-Namen mit der ServerName-Direktive.
Hat Apache den gewünschten Server gefunden, wird der Request-URI standardmäßig auf das Dateisystem des Servers abgebildet (Mapping). Apache nutzt dazu die im URI enthaltene Pfadangabe. In Kombination mit der DocumentRoot ergibt sich der Pfad zur Ressource.
Bei einer Anfrage mit einem Request-URI 'http://www.example.org:80/public_html/images/logo.gif' würde Apache (ausgehend von dem oben dargestellten Beispiel) unter folgendem Dateipfad nach der gewünschten Ressource suchen:
/data/www/example/public_html/images/logo.gifDa 80 der Standard-Port für HTTP ist, wird diese Angabe in der Praxis meist weggelassen.
Darüber hinaus gleicht Apache den Request-URI mit optionalen File- und Directory-Blöcken in der Konfiguration ab. Diese ermöglichen es, spezielle Anweisungen für Requests zu definieren, die sich auf die ausgewählten Dateien oder Verzeichnisse (inklusive Unterverzeichnisse) beziehen.
In folgendem Beispiel wurden spezielle Anweisungen für das Verzeichnis public_html/images und die Datei private.html definiert:
<VirtualHost *:80>
ServerName www.example.com
ServerAlias example.com *.example.com
DocumentRoot /data/www/example
<Directory var/www/example.com/public_html/images>
Order Allow,Deny
Allow from all
</Directory>
<Files public.html>
Order Allow,Deny
Deny from all
</Files>
</VirtualHost>Neben diesem Standardvorgehen bei der Interpretation von Clientanfragen bietet Apache mit der Alias-Direktive die Möglichkeit, ein Alternativ-Verzeichnis anzugeben, das anstelle der DocumentRoot nach der angefragten Ressource durchsucht werden soll. Darüber hinaus hält der Apache HTTP Server mit mod_rewrite ein Modul bereit, das es Nutzern erlaubt, URLs umzuschreiben oder weiterzuleiten.
Mehr zum Server-Modul mod_rewrite finden Sie im Grundlagenartikel zum Thema Rewrite-Engine
Soll Apache Ressourcen abrufen, die Außerhalb des Dateisystems des Servers abgelegt wurden, kommt die Direktive Location zu Einsatz. Diese ermöglicht es, Anweisungen für bestimmte URIs zu definieren.
Was bei Apache eine Ausnahme darstellt, ist bei NGINX der Standardfall. NGINX parst zunächst den Request-URI und gleicht diesen mit Server- und Location-Blöcken in der Webserver-Konfiguration ab. Erst danach findet (bei Bedarf) ein Mapping auf das Dateisystem und die Kombination mit der root (entspricht der DocumentRoot des Apache-Servers) statt.
Mithilfe der Direktive Server ermittelt NGINX, welcher Host für die Beantwortung der Client-Anfrage zuständig ist. Der Server-Block entspricht somit einem VirtualHost in der Apache-Konfiguration. Dazu werden der Host-Name, die IP-Adresse und die Port-Nummer des Request-URI mit allen in der Webserver-Konfiguration definierten Server-Blöcken abgeglichen. Folgendes Codebeispiel zeigt drei Server-Blöcke innerhalb der NGINX-Konfigurationsdatei nginx.conf:
server {
listen 80;
server_name example.org www.example.org;
...
}
server {
listen 80;
server_name example.net www.example.net;
...
}
server {
listen 80;
server_name example.com www.example.com;
...
}Jeder Server-Block beinhaltet in der Regel eine Reihe von Location-Blöcken. Im aktuellen Beispiel wurden diese durch Platzhalter (…) ersetzt.
Ein Abgleich des Request-URI mit den Location-Blöcken innerhalb eines Server-Blocks erfolgt erst, wenn der angefragte Server gefunden wurde. Dazu liest NGINX die aufgeführten Location-Blöcke ein und sucht nach der Location, die mit dem Request-URI am besten übereinstimmt. Jeder Location-Block beinhaltet spezifische Anweisungen, die NGINX anzeigen, wie der entsprechende Request zu bearbeiten ist.
Dabei können Locations so definiert werden, dass sie als Präfix für einen Pfad, als exakte Übereinstimmung oder als Regulärer Ausdruck (Regular Expression, RegEx) interpretiert werden. In der Syntax der Serverkonfiguration kommen dazu u. a. folgende Modifikatoren zum Einsatz:
| kein Modifikator | Die Location wird als Präfix interpretiert. Alle Requests, deren URI das in der Location-Direktive definierte Präfix aufweisen, gelten als mit der Location übereinstimmend. Findet sich keine spezifischere Location, wird der Request gemäß den Angaben in diesem Location-Block verarbeitet. |
| = | Die Location wird als exakte Übereinstimmung interpretiert. Alle Requests, deren URI mit der in der Location-Direktive aufgeführten Zeichenfolge exakt übereinstimmt, werden gemäß den Angaben in diesem Location-Block verarbeitet. |
| ~ | Die Location wird als Regulärer Ausdruck interpretiert. Alle Requests, deren URI mit dem Regulären Ausdruck übereinstimmt, werden gemäß den Angaben in diesem Location-Block verarbeitet. Groß- und Kleinschreibung werden beim Abgleich ausgewertet (case-sensitive). |
| ~* | Die Location wird als Regulärer Ausdruck interpretiert. Alle Requests, deren URI mit dem Regulären Ausdruck übereinstimmt, werden gemäß den Angaben in diesem Location-Block verarbeitet. Groß- und Kleinschreibung werden beim Abgleich nicht ausgewertet (case-insensitive). |
Folgendes Beispiel zeigt drei Location-Blöcke, die anzeigen, wie eingehende Anfragen für die Domains example.org und www.example.org zu bearbeiten sind:
server {
listen 80;
server_name example.org www.example.org;
root /data/www;
location / {
index index.html index.php;
}
location ~* \.(gif|jpg|png)$ {
expires 30d;
}
location ~ \.php$ {
fastcgi_pass localhost:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}Ausgehend von einer Client-Anfrage mit der Request-URI www.example.org:80/logo.gifwürde NGINX folgendermaßen vorgehen, um folgende Anfragen zu interpretieren und die gewünschte Ressource auszuliefern:
http://www.example.org:80/logo.gif
http://www.example.org:80/index.phpZunächst ermittelt NGINX die spezifischste Präfix-Location. Dazu liest der Webserver alle Locations ohne Modifikator der Reihe nach ein und stoppt bei der ersten Location, die mit der Anfrage übereinstimmt. Anschließend werden alle Locations eingelesen, die mit dem RegEx-Modifikator (~) markiert sind. Auch hier kommt der erste Treffer zur Anwendung. Findet sich keine passende RegEx-Location, greift der Webserver auf die zuvor ermittelte Präfix-Location als Fallback zurück.
Der Request-URI www.example.org:80/logo.gif stimmt beispielweise sowohl mit der Präfix-Location / als auch dem Regulären Ausdruck \.(gif|jpg|png)$ überein. NGINX würde die Anfrage daher in Kombination mit der root auf den Dateipfad /data/www/logo.gif abbilden und die entsprechende Ressource an den Client ausliefern. Der Expires-Head gibt an, ab wann eine Antwort als veraltet gilt – im aktuellen Beispiel nach 30 Tagen: expires 30d.
Die Anfrage nach der PHP-Seite mit dem URI www.example.org:80/index.php stimmt ebenfalls mit der Prefix-Location / überein sowie mit der RegEx-Location ~ \.php$, welche bevorzugt behandelt wird. NGINX übergibt die Anfrage daher einem FastCGI-Server, der auf localhost:9000 lauscht und für die Bearbeitung dynamischer Webinhalte zuständig ist. Dabei setzt die Direktive fastcgi_param den FastCGI-Parameter SCRIPT_FILENAME auf /data/www/index.php. Anschließend wird die Datei auf dem Uptream-Server ausgeführt. Die Variable $document_root entspricht dabei der root-Direktive, die Variable $fastcgi_script_name dem Teil der URI, der auf Host-Name und Port-Nummer folgt: /index.php.
Dieses auf den ersten Blick etwas kompliziert erscheinende Vorgehen bei der Interpretation von Clientanfragen ist den verschiedenen Anwendungsfeldern geschuldet, in denen NGINX zum Einsatz kommt. Im Vergleich zum primär dateibasierten Vorgehen des Apache HTTP Servers ermöglicht die URI-basierte Interpretation von Requests eine größere Flexibilität bei der Bearbeitung unterschiedlicher Anfragemuster. Benötigt wird dies beispielsweise dann, wenn NGINX nicht als Web- sondern als Proxy- oder Mail-Proxy-Server fungiert.
Apache wird in erster Linie als Webserver eingesetzt und interpretiert Clientanfragen primär dateibasiert. NGINX hingegen arbeitet standardmäßig mit URIs und wird so auch anderen Anfragemustern gerecht.
Konfiguration
NGINX wird gegenüber dem Apache HTTP Server ein enormer Geschwindigkeitsvorteil bei der Auslieferung von statischen Webinhalten nachgesagt. Dieser ist u. a. auf Unterschiede bei der Konfiguration zurückzuführen. Der Apache-Webserver bietet Administratoren neben der Hauptkonfigurationsdatei httpd.conf die Möglichkeit einer Verwaltung auf Verzeichnisebene. Dazu kommen sogenannte .htaccess-Dateien zum Einsatz. Diese dezentralen Konfigurationsdateien lassen sich prinzipiell in jedem beliebigen Server-Verzeichnis implementieren. Anweisungen, die in einer .htaccess definiert wurden, beziehen sich sowohl auf das Verzeichnis, das die Konfigurationsdatei enthält, als auch auf dessen Unterverzeichnisse. In der Praxis kommen .htaccess-Dateien zum Einsatz, um den Verzeichniszugriff auf bestimmte Nutzerkreise zu beschränken, einen Passwortschutz einzurichten sowie Regelungen für das Verzeichnis-Browsing, Fehlermeldungen, Weiterleitungen oder alternative Inhalte zu definieren. Zu beachten ist, dass sich all dies auch zentral in der httpd.conf-Datei konfigurieren ließe. Relevant wird die .htaccess jedoch bei Webhosting-Modellen wie dem Shared Hosting, bei dem der Zugriff auf die Hauptkonfigurationsdatei dem Hosting-Dienstleister vorbehalten ist. Die dezentrale Konfiguration via .htaccess ermöglicht es, Nutzern die Administration für bestimmte Bereiche des Server-Dateisystems – beispielsweise für ausgewählte Projektverzeichnisse – zu erlauben, ohne ihnen Zugriff auf die Hauptkonfiguration zu gewähren. Außerdem treten Änderungen sofort und ohne Neustart in Kraft. NGINX hingegen bietet lediglich zentrale Konfigurationsmöglichkeiten. Sämtliche Anweisungen werden in der Datei nginx.conf definiert. Mit dem Zugriff auf diese Datei erhält ein Nutzer die Kontrolle über den gesamten Server. Anders als bei Apache lässt sich der administrative Zugang somit nicht auf ausgewählte Verzeichnisse beschränken. Dies hat sowohl Vor- als auch Nachteile. Die zentrale Konfiguration von NGINX ist weniger flexibel als das Konzept des Apache HTTP Servers, bietet jedoch einen deutlichen Sicherheitsvorteil: Änderungen an der Konfiguration des Webservers können nur von Nutzern vorgenommen werden, die über Root-Rechte verfügen. Wichtiger jedoch als das Sicherheitsargument ist der Performance-Nachteil einer dezentralen Konfiguration via .htaccess. Bereits in der Dokumentation des Apache HTTP Servers empfehlen die Entwickler, auf den Gebrauch der .htaccess zu verzichten, sofern ein Zugriff die httpd.conf möglich ist. Grund dafür ist die Prozedur, in der Apache Konfigurationsdateien einliest und interpretiert. Wie bereits angesprochen folgt Apache standardmäßig einem dateibasierten Schema, um Clientanfragen zu beantworten. Da die Apache-Architektur eine dezentrale Konfiguration ermöglicht, durchsucht der Webserver auf dem Weg zur angefragten Ressource jedes Verzeichnis entlang des Dateipfades nach einer .htaccess-Datei. Alle Konfigurationsdateien, die er dabei passiert, werden eingelesen und interpretiert – ein Schema, das den Webserver deutlich ausbremst.
Prinzipiell ist es Apache-Administratoren freigestellt, ob sie auf die dezentralen Konfigurationsmöglichkeiten des Webservers zurückgreifen und die damit zusammenhängenden Vor- und Nachteile in Kauf nehmen möchten. In der Dokumentation betonen die Entwickler, dass alle .htaccess-Konfigurationen mittels Directory-Blöcken auch in der Hauptkonfiguration httpd.conf vorgenommen werden können.
Anwender, die die dezentrale Konfiguration unter Apache deaktivieren oder einschränken möchten, nutzen dafür die Direktive AllowOverride in Directory-Blöcken der Hauptkonfigurationsdatei httpd.conf und setzten setzen diese auf None. Dies weist den Webserver an, alle .htaccess-Dateien in entsprechend konfigurierten Verzeichnissen zu ignorieren.
<VirtualHost *:80>
ServerName example.com;
...
DocumentRoot /data/www/example
<Directory /data/www/example>
AllowOverride None
...
</Directory>
...
</VirtualHost>Die Beispielkonfiguration weist den Webserver an, alle .htaccess-Dateien für den Host example.com zu ignorieren.
Anders als NGINX, der lediglich zentral konfiguriert wird, bietet der Apache mit .htaccess die Möglichkeit der dezentralen, verzeichnisbasierten Konfiguration. Kommen .htaccess-Dateien zum Einsatz, büßt der Webserver jedoch Geschwindigkeit ein.
Erweiterungsmöglichkeiten
Beide Webserver in unserem Vergleich setzen auf ein modulares System, bei dem die Kern-Software bei Bedarf um zusätzliche Komponenten erweitert werden kann. Doch bis Version 1.9.10 verfolgte NGINX beim Umgang mit Modulen eine grundsätzlich andere Strategie als das Konkurrenzprodukt. Der Apache HTTP Server stellt zwei Möglichkeiten zur Verfügung, die Kern-Software zu erweitern. Module lassen sich entweder während der Entwicklung in die Apache-Binärdateien kompilieren oder dynamisch und somit während der Laufzeit laden. Es lassen sich drei Kategorien von Apache-Modulen unterscheiden:
- Basismodule: Die Apache-Basismodule umfassen alle Komponenten, die die Kernfunktionalitäten des Webservers zur Verfügung stellen.
- Erweiterungsmodule: Bei diesen Erweiterungen handelt es sich um Module der Apache Foundation, die als Bestandteil der Apache Distribution mitgeliefert werden. Einen Überblick über alle in der Apache-2.4-Standardinstallation enthaltenen Module bietet die Apache-Dokumentation.
- Drittanbietermodule: Diese Module werden nicht von der Apache-Foundation, sondern von externen Dienstleistern oder selbstständigen Programmierern zur Verfügung gestellt.
Bei NGINX hingegen beschränkte sich die Modularität lange auf statische Erweiterungskomponenten, die in die Binärdatei des Software-Kerns kompiliert werden mussten. Gerade für Anwender, die es nicht gewohnt waren, eigene Software-Komponenten ohne den Paketmanager der jeweiligen Distribution zu verwalten, schränkte diese Art der Software-Erweiterung die Flexibilität des Webservers deutlich ein. Das Entwickler-Team hat in diesem Punkt nachgebessert: Seit Version 1.9.11 (Release 09.02.2016) unterstützt NGINX Mechanismen, die es ermöglichen, statische Module in dynamische zu konvertieren, sodass diese während der Laufzeit über Konfigurationsdateien geladen werden können. In beiden Fällen kommt die Modul-API des Servers zum Einsatz. Dabei ist zu beachten, dass sich nicht alle NGINX-Module in dynamische Module konvertieren lassen. Module, die den Quellcode der Server-Software patchen, sollten nicht dynamisch geladen werden. Zudem limitiert NGINX die Anzahl dynamischer Module, die gleichzeitig geladen werden können, in der Standardeinstellung auf 128. Um diesen Grenzwert zu erhöhen, setzen Sie die Konstante bei NGX_MAX_DYNAMIC_MODULES im NGINX-Quellcode auf den gewünschten Wert. Zusätzlich zu den offiziellen Modulen der NGINX-Dokumentation stehen Anwendern diverse Drittanbietermodule bereit.
Beide Webserver lassen sich modular erweitern. Neben statischen Modulen stehen dynamische Module zur Verfügung, die bei Bedarf in das laufende Programm geladen werden können.
Dokumentation und Support
Beide Software-Projekte sind gut dokumentiert und stellen Anwendern über Wikis und Blogs Informationen aus erster Hand zur Verfügung.
Während sich die NGINX-Dokumentation nur auf Englisch und Russisch abrufen lässt, zeichnet sich das Apache-Projekt durch Informationsmaterialien in zahlreichen Sprachversionen aus. Diese sind jedoch teilweise veraltet, sodass ein Blick in die englische Dokumentation auch hier unerlässlich ist. Hilfe bei Problemen erhalten Nutzer bei beiden Open-Source-Projekten über die Community. Dabei fungieren Mailinglisten als Diskussionsforen.
- Apache HTTP Server: Mailinglisten
- NGINX: Mailinglisten
Transparente Release-Pläne und Roadmaps geben Nutzern die Möglichkeit, sich auf zukünftige Entwicklungen einzustellen. Software-Fehler und Sicherheitslücken werden bei beiden Projekten in einem öffentlichen Bug-Report erfasst und aufgearbeitet.
- Apache HTTP Server: Bug-Report
- NGINX: Bug-Report
Zusätzlich zum Open-Source-Projekt NGINX bietet die Nginx, Inc. das kommerzielle Produkt NGINX Plus an. Gegen eine jährliche Nutzungsgebühr sichern sich Anwender zusätzliche Funktionen sowie eine professionellen Support durch den Hersteller. Eine Vergleichsmatrix beider Produkte finden Sie auf der NGINX-Website. Eine kommerzielle Edition des Apache HTTP Servers existiert nicht. Kostenpflichtige Support-Dienstleistungen werden jedoch durch diverse Drittanbieter angeboten.
Sowohl der Apache HTTP Server als auch NGINX sind für einen professionellen Einsatz auf Produktivsystemen ausreichend dokumentiert.
Kompatibilität und Ökosystem
Der Apache HTTP Server prägt das World Wide Web seit mehr als zwei Dekaden und gilt aufgrund des Marktanteils nach wie vor als De-facto-Standard für die Bereitstellung von Webinhalten. Auch NGINX kann auf eine 15-jährige Erfolgsgeschichte zurückblicken. Beide Webserver zeichnen sich durch eine breite Plattformunterstützung aus. Während der Apache für alle unixoiden Betriebssysteme sowie für Windows empfohlen wird, führt die NGINX-Dokumentation folgende Systeme als getestet an: FreeBSD, Linux, Solaris, IBM AIX, HP-UX, macOS und Windows. Als Standard-Server zeichnet sich der Apache durch eine weitgehende Kompatibilität zu Drittanbieter-Projekten aus. Alle relevanten Webstandards lassen sich über Module integrieren. Hinzu kommt, dass ein Großteil der Akteure im Netz mit den Konzepten des Apache vertraut sind. Administratoren und Webentwickler setzen ihre ersten Projekte in der Regel auf kostengünstigen Shared-Hosting-Plattformen um. Diese wiederum basieren mehrheitlich auf Apache und der Möglichkeit einer dezentralen Konfiguration via .htaccess. Darüber hinaus ist der Apache HTTP Server Teil diverser quelloffener Programmpakete für Entwicklung und Software-Tests wie XAMPP oder AMPPS. Auch NGINX stellt Anwendern ein großes Ökosystem an Modulen zur Verfügung. Darüber hinaus pflegt das Entwickler-Team Partnerschaften zu diversen quelloffenen und proprietären Software-Projekten sowie zu Infrastruktur-Dienstleistern wie Amazon Web Services, Windows Azure und HP.
Beide Webserver sind etabliert. Anwender können auf ein großes Ökosystem zurückgreifen. Apache hat im Vergleich zu NGINX den Vorteil, dass sich im Laufe der Jahre eine große Nutzergemeinde in die Grundlagen des Webservers eingelesen hat. Dass Tausende von Administratoren den Quellcode der Software geprüft und verbessert haben, spricht nicht nur für die Sicherheit des Webservers. Auch neue Nutzer profitieren von der großen Anzahl erfahrener Apache-Administratoren, die der Community bei Problemen in Foren oder über Mailinglisten zur Seite stehen.
NGINX vs. Apache: Die Unterschiede im Überblick
Trotz der großen Unterschiede in der Software-Architektur bieten beide Webserver ähnliche Funktionen. Apache und NGINX kommen in vergleichbaren Szenarios zum Einsatz, greifen dabei jedoch auf jeweils eigene Strategien und Konzepte zurück, um den Anforderungen gerecht zu werden. Die nachfolgende Tabelle stellt beide Software-Projekte anhand zentraler Merkmale gegenüber und zeigt Schnittpunkte und Abweichungen auf.
| Merkmal | Apache | NGINX |
| Funktion | Webserver Proxy-Server | Webserver Proxy-Server E-Mail-Proxy Load-Balancer |
| Programmiersprache | C | C |
| Betriebssystem | Alle unixoiden Plattformen Windows | FreeBSD Linux Solaris IBM AIX HP-UX macOS Windows |
| Veröffentlichung | 1995 | 2002 |
| Lizenz | Apache License v2.0 | BSD-Lizenz (Berkeley Software Distribution) |
| Entwickler | Apache Software Foundation | Nginx, Inc. |
| Software-Architektur | Prozess-/threadbasiert | Eventgesteuert |
| Nebenläufigkeit | Multi-Processing Multi-Threading | Event-Loop |
| Statische Webinhalte | Ja | Ja |
| Dynamische Webinhalte | Ja | Nein |
| Interpretation von Clientanfragen | Primär dateibasiert | URI-basiert |
| Konfiguration | Zentrale Konfiguration via httpd.conf Dezentrale Konfiguration via .htaccess | Zentrale Konfiguration via nginx.conf |
| Erweiterungsmöglichkeiten | Statische Module Dynamische Module | Statische Module Dynamische Module |
| Dokumentation | Deutsch Englisch Dänisch Spanisch Französisch Japanisch Koreanisch Portugiesisch Türkisch Chinesisch | Deutsch Englisch |
| Support durch Entwickler | Nein | Ja (kostenpflichtig über Nginx, Inc.) |
| Community-Support | Mailinglisten Wiki | Mailinglisten Wiki |
Fazit
Mit Apache und NGINX stehen Anwendern zwei stabile, sichere Open-Source-Projekte zur Verfügung. Als klarer Gewinner geht jedoch keiner der beiden Webserver aus diesem Vergleich hervor. Beiden Projekten liegen grundverschiedene Design-Entscheidungen zugrunde, die je nachdem, wie die Software zum Einsatz kommt, Vorteile oder Nachteile mit sich bringen.
Der Apache HTTP Server bietet ein immenses Repertoire an Modulen, das der Software zusammen mit den flexiblen Konfigurationsmöglichkeiten zahlreiche Anwendungsfelder eröffnet. Der Webserver gilt als Standard-Software für Shared-Hosting-Szenarien und wird sich in diesem Geschäftsfeld auch zukünftig gegen leichtgewichtige Webserver wie NGINX behaupten. Die Möglichkeit, Interpreter für Programmiersprachen wie PHP, Perl, Python oder Ruby über Module direkt in den Webserver zu integrieren, erlaubt die Auslieferung dynamischer Webinhalte ohne einen separaten Anwendungsserver. Dies macht den Apache HTTP Server zu einer bequemen Lösung für kleine und mittelgroße Websites, bei denen Inhalte während des Abrufs dynamisch erzeugt werden.
NGINX hingegen bietet keine Möglichkeit, dynamische Webinhalte nativ zu verarbeiten oder entsprechende Interpreter durch Module einzubinden. Es wird somit in jedem Fall ein separater Anwendungsserver benötigt. Dies mag bei kleinen bis mittelgroßen Websites als ein unnötiger Mehraufwand erscheinen. Seine Stärken zeigt ein solcher Aufbau jedoch bei großen Webprojekten und steigendem Traffic-Aufkommen.
In der Regel kommt NGINX als Load-Balancer vor einer Gruppe von Anwendungsservern zum Einsatz. Dabei nimmt der Load-Balancer eingehende Anfragen entgegen und entscheidet je nach Art des Requests, ob dieser an einen spezialisierten Server im Hintergrund weitergeleitet werden muss. Statische Webinhalte werden direkt von NGINX ausgeliefert. Fordert ein Client hingegen dynamische Inhalte an, gibt der Load-Balancer den Request an einen dafür vorgesehenen Anwendungsserver weiter. Dieser interpretiert die Programmiersprache, setzt die angeforderten Inhalte zu einer Webpage zusammen und gibt diese an den Load-Balancer zurück, der wiederum die Auslieferung an den Client übernimmt. Auf diese Weise lassen sich hohe Traffic-Aufkommen effektiv bewältigen.
Hinzu kommt, dass NGINX bereits ausgelieferte Inhalte für eine gewisse Zeit im Cache vorhält, sodass erneut angefragte dynamische Inhalte direkt vom Load-Balancer ausgeliefert werden können, ohne dass NGINX erneut auf einen Anwendungsserver zurückgreifen muss.
Die Auslagerung des Interpreters auf einen oder mehrere separate Backend-Server hat den Vorteil, dass sich der Serververbund bequem skalieren lässt, indem bei Bedarf zusätzliche Backend-Server hinzugezogen oder nicht benötigte Systeme abgeschaltet werden können. In der Praxis setzen viele Anwender bei einem solchen Aufbau auf die Kombination von NGINX und Apache und nutzen somit die Stärken beider Webserver.