Je nach Statistik ist Apache der verbreitetste Webserver, oder es steht Nginx auf Platz 1. Solche Messungen sind durchaus mit Vorsicht zu genießen: Sie erfassen oft nur einen Teil des Internets und nicht jede Seite gibt bekannt, welche Technologie sie einsetzt. Unbestritten ist dagegen, dass sowohl Apache als auch Nginx zu den verbreitetsten Webservern gehören und damit ein wesentlicher Bestandteil des heutigen Internets sind. Doch worin unterscheiden sie sich? Welcher davon ist besser? Nachdem ich beide über Jahre hinweg eingesetzt habe, werden wir uns die Webserver genauer anschauen und die Fragen im Anschluss klären.
Apache: Das Urgestein des WWW
Die Entwicklung von Apache geht bis in die frühen 1990er Jahre zurück: Sie erweiterten den 1993 erschienenen NCSA HTTPd. Er wurde am Nationalen Zentrum für Supercomputer-Anwendungen in den USA als einer der ersten Webserver entwickelt. Als einer der ursprünglichen Entwickler das Zentrum mitte 1994 verlässt, verlangsamt sich die Entwicklung stark. Im selben Jahr erweitern acht unabhängige Entwickler HTTPd und veröffentlichten ihre Änderungen 1995 unter dem Name Apache HTTP Server. Er war das Gründungsprojekt der 1999 gegründeten Apache Software-Stiftung, die bis heute eine Vielzahl an verbreiteten Open Source Projekten betreut. Sie haben für den Webserver ihre eigene Apache-Lizenz entwickelt.
Nginx setzt den Fokus auf Leistung
Der Nginx-Webserver erschien dagegen erst im Jahre 2004. Er wurde für die russische Suchmaschine Rambler entwickelt, die bereits im Jahr 2000 mehr als eine Milliarde Suchanfragen erhielt. Wichtig war daher eine hohe Leistung bei geringem Ressourcenverbrauch. Hier schneidet er deutlich besser ab als Apache und ist zudem ebenfalls quelloffen unter der BSD-Lizenz – daher verliert Apache bereits seit einigen Jahren Marktanteile an Nginx. In den Top 1.000 Seiten mit dem höchsten Datenvolumen erreichte Nginx im Mai 2022 einen Marktanteil von über 46%, Apache mehr als 31%.
Worin unterscheiden sich Nginx und Apache konkret?
Architektur
Apache besitzt eine prozessbasierte Architektur, bei dem pro Anfrage ein Kindprozess (mpm_prefork) oder Thread (mpm_worker) gestartet wird. Threads verbrauchen weniger Ressourcen, allerdings kann sich hier ein fehlerhafter Prozess auch auf andere Verbinden auswirken. Dies ist bei mpm_prefork nicht der Fall, da jede Verbindung ihren eigenen Prozess erhält. Um den physischen Server nicht zu überlasten, gibt es für beide Module Limits. Werden mehr Threads oder Prozesse benötigt als zur Verfügung stehen, müssen Anfragen warten.
Das wird vor allem mit Keep-Alive zum Problem: Hier werden Verbindungen bewusst über einen längeren Zeitraum offen gehalten – belegen in dieser Zeit aber einen Thread bzw. Prozess. Dies kann bei hoher Anzahl zur Überlastung des Servers führen. Seit Apache 2.4 gibt es mit mpm_event eine Alternative. Es bietet eine bessere Lastverteilung und lagert Keep-Alive Verbindungen in einen eigenen Thread aus, damit neue Anfragen nicht blockiert werden.
Leistung
Am meisten Ressourcen benötigt mpm_prefork: Für jede Verbindung muss ein eigener Prozess gestartet und in ihm jedes Apache-Modul geladen werden. Da ein Thread im Kontext des Programms läuft, ist dies nicht notwendig – hier reicht einmaliges laden, damit alle Threads gemeinsam darauf zugreifen können. mpm_worker und mpm_event sind daher bereits deutlich effizienter. Allerdings müssen beide Module zwischen den Threads wechseln. Diese Kontextwechsel sind rechenintensiv, da der bestehende Kontext gesichert und der neue geladen werden muss.
Nginx setzt auf eine eventbasierte Architektur, hat mit dem mpm_event Modul von Apache jedoch wenig gemeinsam: Es gibt eine Schleife (Event-Loop), die mehrere tausend Anfragen gleichzeitig annehmen und verarbeiten kann. Dies erfolgt asynchron und kann daher in einem einzigen Thread ablaufen – Kontextwechsel entfallen daher komplett.
Vereinfacht gesagt übergibt Nginx Aufgaben an das Betriebssystem, etwa den Inhalt einer Datei auszulesen und merkt sich dies. Statt auf das Ergebnis zu warten (was relativ lange dauert) und dadurch blockiert zu sein, werden zeitgleich andere Aufgaben erledigt, etwa die nächste Anfrage anzunehmen. Hat das Betriebssystem die zuvor delegierte Aufgabe (hier das auslesen einer Datei) erledigt, wird dies per Rückruffunktion (Callback) an Nginx gemeldet. Da Nginx sich dies gemerkt hat, sendet es den Dateiinhalt an die entsprechende Anfrage.
Bei Apache müsste zunächst ein Thread bzw. Prozess gestartet werden. Dieser wäre blockiert, bis die Datei eingelesen und an den Client gesendet wurde. Beides ist bei Nginx nicht der Fall, sodass dieser Webserver mehr Durchsatz bei geringerem Ressourcenverbrauch erzielen kann.
Dynamische Inhalte
Heutzutage müssen Webserver nicht nur statische Inhalte wie HTML-Seiten, CSS, Bilder etc. ausliefern. Nahezu überall werden Inhalte dynamisch mit PHP, Python, Java und anderen Technologien dynamisch generiert. Diese können in Apache mit Modulen wie mod_php, mod_python usw. integriert werden. Dies ist bequem, allerdings müssen diese Module in jedem Arbeitsprozess geladen werden. Auch wenn dieser nur statische Inhalte ausliefert, wird z.B. das PHP-Modul geladen. Außerdem startet Apache für jede Anfrage einen eigenen PHP-Prozess.
Nginx bietet keine solche Integration und kann nativ nur statische Inhalte ausliefern. Für dynamische Inhalte gibt es Schnittstellen wie z.B. FastCGI, um diese an einen eigenen Server auszulagern. Bei PHP wäre dies beispielsweise PHP-FPM. Der Vorteil: Durch die Auslagerung steigt die Effizienz. PHP, Python oder was man nutzen möchte wird nur für die Skripte geladen. Ein Prozessmanager wie PHP-FPM bietet darüber hinaus weitere Optimierungen. Beispielsweise kann er X PHP-Prozesse gestartet halten. Damit entfällt der Aufwand und die Verzögerung, für jede Anfrage zunächst einen eigenen Prozess starten zu müssen.
Apache hat hier allerdings bereits vor einiger Zeit nachgebessert: Über das Modul mod_proxy_fcgi kann man seit Version 2.3 auch einen externen Anwendungsserver per FastCGI anbinden. Somit hat man heutzutage bei Apache die Wahl, ob man die eingebetteten Module oder FastCGI verwenden möchte.
Module
Sowohl Apache als auch Nginx lassen sich über verschiedene Module erweitern. Im Umgang damit gibt es aber einen großen Unterschied: Apache erlaubt es, Module jederzeit einfach zu installieren, zu aktivieren oder zu deaktivieren. Beispielsweise kann man ein Modul nur für eine bestimmte Seite laden. Bei Nginx müssen Module dagegen einkompiliert werden. Wer ein Modul verwenden möchte, dass nicht im Standard enthalten ist (z.B. Brotli), muss Nginx zusammen mit diesem kompilieren. Wie das funktioniert, habe ich in einem eigenen Beitrag bereits erklärt. Das feste einkompilieren hat bei Nginx allerdings Performance-Vorteile gegenüber des dynamischen Ladens bei Apache.
Der Nachteil: Man erhält keine zentralen Aktualisierungen mehr über die Paketverwaltung oder Docker-Images. Bei jeder Änderung muss man sich den Quellcode herunterladen und Nginx neu kompilieren. Dynamische Module gibt es nur in Nginx Plus. Diese Version ist kostenpflichtig, enthält Support und einige Sonderfunktionen. Es lassen sich allerdings auch mit Nginx Plus nicht alle Module dynamisch laden.
Konfiguration
Beide Webserver besitzen eine zentrale Konfigurationsdatei httpd.conf (Apache) bzw nginx.conf für Nginx. Apache bietet zusätzlich die Möglichkeit, in jedem Verzeichnis einer Webseite (DocumentRoot) eine .htaccess Datei zu platzieren. Mit ihr kann man die zentrale Konfiguration ergänzen, jeweils für das aktuelle Verzeichnis und ggf. auch die Unterverzeichnisse.
Das kann praktisch sein, wenn sich mehrere Personen einen Server teilen. So kann jeder eigenständig seine Seite konfigurieren, ohne dass der Administrator jede Änderung an der zentralen httpd.conf vornehmen muss. Allerdings ist dieser dezentrale Ansatz schlecht für die Leistung: Bei jeder Anfrage durchsucht Apache das Dateisystem nach möglicherweise vorhandenen .htaccess Dateien. Das verursacht zusätzliche Last und verzögert die Auslieferung. Außerdem kann dies ein mögliches Sicherheitsrisiko sein, weswegen empfohlen wird, dies mit AllowOverride None zu deaktivieren, sofern man die Funktionalität nicht zwingend benötigt.
Unterstützung
Nginx und Apache liefern eine solide Dokumentation, die allerdings bei Nginx nur in Englisch und Russisch verfügbar ist. Apache liefert eine deutsche Dokumentation – vor allem für Neulinge kann dies sicher eine Hilfe sein. Allerdings ist die deutsche Variante teilweise nicht immer aktuell, sodass die englische Fassung tendenziell zu bevorzugen ist. Vereinzelt finde ich die Inhalte bei Nginx etwas knapp.
Im Falle von Fragen oder Problemen existiert für beide Webserver eine große Nutzergemeinde. Man findet zahlreiche Artikel, Forenbeiträge und andere Quellen, die verschiedene Szenarien beschreiben und wo man bei Bedarf auch selbst um Hilfe bitten kann.
Kompatibilität und Ökosystem
Die breiteste Kompatibilität findet man bei Apache: Der Webserver existiert seit etwa drei Jahrzehnten und hat sich bereits vor langem zum Quasi-Standard entwickelt. Vor allem auf gemeinsam genutzten Webspace-Paketen wird er oft eingesetzt. Viele Webanwendungen sind daher mit Apache kompatibel. Die Funktionen können über zahlreiche Erweiterungen ergänzt werden. Damit lassen sich nicht nur alle gängigen Standards umsetzen, sondern bei Bedarf auch kreativere Workarounds. So erlaubt das Modul mod_substitute etwa bestimmte Muster zu ersetzen, bevor Apache diese ausliefert.
Vor einigen Jahren genoss Nginx bei diesen Aspekten eher ein Nischendasein, wird aber auch zunehmend unterstützt. Die Anzahl der Module hat ebenfalls zugenommen. Für alle Erweiterungen die nicht zum Kern gehören, muss allerdings der gesamte Webserver neu kompiliert werden.
Alternative: Apache und Nginx einsetzen
Man kann auch beide Webserver gemeinsam einsetzen. Gängig ist beispielsweise, statische Inhalte von Nginx auszuliefern und nur (bestimmte) dynamische Anfragen an Apache weiterzuleiten. So lassen sich die Vor- und Nachteile beider Programme erheblich ausgleichen: Nginx liefert effizient statische Dateien aus, während Apache mit seiner vollen Flexibilität für den Rest zur Verfügung steht. Nginx lauscht dafür auf den Standartports 80/443, während Apache einen anderen (ausschließlich intern genutzten) Port erhält, etwa 81.
Dies ist beispielsweise dann sinnvoll, wenn man für eine recht stark besuchte Seite spezielle Funktionen von Apache benötigt, aber Leistung und Ressourcenverbrauch optimieren möchte. In den meisten Fällen reicht aber ein Webserver.
Fazit und Entscheidungshilfe: Nginx oder Apache?
Nginx ist auf Leistung und Effizient optimiert – Apache dagegen eher auf Einfachheit, Flexibilität und breite Kompatibilität. So könnte man die Unterschiede grob in einem Satz zusammenfassen. Es ist daher schwer, pauschal einen als besser oder schlechter zu beurteilen. Für welchen Webserver sollte man sich nun entscheiden? Ich würde folgende Kriterien zu Hilfe nehmen:
- Apache eignet sich gut für Einsteiger, da man vergleichsweise einfach die eingebetteten Interpreter für z.B. PHP, Python & co. nutzen kann und sich viele Module per APT-Pakete nachinstallieren lassen
- Vor allem bei kleinen und teils auch mittelgroßen Seiten sind die Performance-Unterschiede oft vernachlässigbar, selbst auf einem Raspberry Pi (so lange es nicht gerade ein schwaches Modell mit einer sehr komplexen Webanwendung ist)
- Wenn die benötigten Funktionen überschaubar sind, kann man Nginx einsetzen – vor allem als Reverse Proxy reicht dieser oft völlig aus. Wobei gerade im Docker-Umfeld auch Traefik eine gute Figur macht und zudem weitere Vorteile bietet.
- Wer bereits grundlegende Erfahrung hat, kann mithilfe von Nginx das letzte aus seiner Infrastruktur herauskitzeln – die etwas komplexeren Konfiguration dürfte mit entsprechendem Vorwissen keine zu große Hürde sein.
- Man sollte sich im Einzelfall auch immer nach der eingesetzten Software richten. Unterstützt diese z.B. nur Apache, setzt man andere Webserver wie Nginx auf eigenes Risiko ein. Die Konfiguration kann Mehraufwand bedeuten und möglicherweise treten Probleme auf, die man im Zweifel zudem selbst lösen muss.
- Gerade bei schwächerer Hardware (z.B. ältere Raspberry Pis oder Zero) machen leichtgewichtigere Webserver Sinn, da der Unterschied unter diesen Umständen deutlich spürbar sein kann. Hier bieten sich ggf. sogar noch leichtgewichtigere Projekte an. Bei solchen Alternativen sollte man die Funktionen jedoch genau prüfen, da diese oft eher spezifisch statt flexibel sind und daher ggf. Standardfunktionen vollwertiger Webserver fehlen können.
Schlussendlich sollte man sich aber auch nicht vergessen: Die Unterschiede liegen im Detail. Viele vor allem Grundlegende Szenarien lassen sich mit Apache, Nginx eben so abbilden wie mit anderen weniger verbreiteten Webservern ebenfalls. Und die Entscheidung ist nicht in Stein gemeißelt. Wer Nginx ausprobiert und merkt, dass er damit nicht gut zurecht kommt, kann in den meisten Fällen jederzeit zu Apache wechseln und umgekehrt.
Die größten Unterschiede zeigen sich bei stark frequentierten Seiten. Hier kann man mit Nginx die Leistung verbessern und zeitgleich sogar durch schwächere Server Kosten sparen. Bei einer privaten Nextcloud oder anderen Software mit 5 Benutzern ist der Mehrwert von Nginx in dieser Hinsicht eher überschaubar.