Nginx gegen Apache: Webserver Showdown

Das Internet, wie wir es heute kennen, begann seine globale „Eroberung“ in den 90er Jahren. Das gesamte „Web“-Protokoll kann als Besucher zusammengefasst werden, der ein Dokument von einer bestimmten Webadresse anfordert, wobei DNS und IP-System diese Anforderung an den richtigen Computer weiterleiten. Dieser Computer, der die angeforderte Webseite hostet, „liefert“ die Webseite zurück an den Besucher.

Webseiten sind im Wesentlichen HTML-Dokumente. Um den Besuchern verschiedene Webseiten zur Verfügung stellen zu können, benötigt der „bedienende“ Rechner ein Serverprogramm. Software wie Nginx oder Apache verarbeitet Anfragen, analysiert sie und gibt dann die entsprechenden Dokumente zurück, die im Browser eines Besuchers angezeigt werden.

Apache

Wir stellen zuerst Apache vor, da es zuerst veröffentlicht wurde.

Nachdem Tim Berners-Lee’s CERN httpd und NCSA HTTPd in den ersten Jahren des Internets, hat Apache – erstmals 1995 veröffentlicht – schnell den Markt erobert und sich zum beliebtesten Webserver der Welt entwickelt. Heute befindet es sich zwar immer noch in dieser Marktposition, aber vor allem dank seines Vermächtnisses. Apache wird von der Apache Foundation unter der Apache-Lizenz entwickelt und gepflegt.

Es gibt zwei verschiedene Geschichten darüber, wie Apache seinen Namen erlangt hat. Eine Version sagt, dass der Name aus dem berühmten indianischen Erbe stammt, während die andere sagt, dass der Name ein Wortspiel auf „einen unregelmäßigen Server“ ist, der einer Reihe von Software-Patches folgte.

Linux

Der enorme Marktanteil von Apache ist zum Teil darauf zurückzuführen, dass er mit allen wichtigen Linux-Distributionen wie Red Hat/Centos und Ubuntu vorinstalliert ist.

Ein Beispiel für die wichtige Rolle von Apache in der Linux-Welt ist, dass sein Serverprozessname HTTPd ist, was Apache zu einem Synonym für Webserver-Software macht.

Abgesehen davon, dass er der erste ernstzunehmende Akteur auf dem Webserver-Markt ist, ist ein Teil der Verbreitung von Apache auf sein Konfigurationssystem und seine .htaccess-Datei zurückzuführen.

.htaccess

Apache verwendet für seine Konfiguration .htaccess. Es gibt viele Tutorials zur Konfiguration, Bearbeitung und Arbeit mit dieser Datei, da sie eine große Flexibilität bei der Konfiguration der Behandlung eingehender Anfragen durch Apache bietet. Einige Beispiele sind: verschiedene Umleitungsregeln, maximale Upload-Dateigrößen, URL-Rewrites, Speicherlimits, Verzeichnisschutz (htpasswd), ablaufende Header, Cache-Control-Header, Codierungsheader, Cookies, Manipulationen von Query-Strings.

Auf der anderen Seite verwendet Kinsta Nginx, das .htaccess-Dateien nicht unterstützt. Einstellungen und Regeln aus deinen .htaccess-Dateien können jedoch leicht in die eigene Rewrite-Regelsyntax von Nginx „übersetzt“ werden.

Einer der Hauptvorteile von Apache ist, dass im Server-Root – dem Hauptverzeichnis der Website – jede Ebene oder jedes Verzeichnis im Verzeichnisbaum eine eigene .htaccess-Datei mit eigener Konfiguration haben kann.

Für Shared Hosting-Provider ist dies ein Traum, denn sie können Hunderten von Benutzern auf derselben Maschine eine Möglichkeit bieten, zu konfigurieren, wie ihre Websites bedient werden, ohne dass dies die anderen beeinträchtigt. Kunden können viele Details in einer eingeschränkten Shared Hosting-Umgebung konfigurieren, ohne die globale Serverkonfiguration zu berühren.

Wie in der offiziellen Dokumentation beschrieben:

„Im Allgemeinen sollten Sie .htaccess-Dateien nur verwenden, wenn Sie keinen Zugriff auf die Konfigurationsdatei des Hauptservers haben.“

Diese Flexibilität geht jedoch zu Lasten der Performance „Das Zulassen von.htaccess-Dateien verursacht einen Performance-Schaden, unabhängig davon, ob Sie sie tatsächlich verwenden oder nicht!“

Bei jeder Aktivierung von .htaccess-Dateien muss Apache den gesamten Verzeichnisbaum von der angeforderten URL oder Datei über alle höheren Ebenen bis hin zum Root-Verzeichnis des Servers durchlaufen und diese dann für jede einzelne Anfrage laden. Anschließend muss es diese Dateien verarbeiten und sich für jedes der auf diese Weise konfigurierten Verzeichnisse neu konfigurieren.

Mit WordPress Websites können die Dinge wirklich komplex werden. Eine typische WordPress Website kann Hunderte von Anfragen aus verschiedenen Verzeichnissen haben.

Von /wp-content/uploads/yyyyyyy/mm Art der Verzeichnisse hat es typischerweise mehrere Anfragen auf einer einzigen Seite geladen, oft aus verschiedenen Monatsverzeichnissen. Dann gibt es /wp-content/themes/parent-theme statische Ressourcen, /wp-content/themes/child-theme Ressourcen: dazu gehören Javascript, CSS-Dateien, Bilder.

Dann wird es auch /wp-content/plugins mit statischen Dateien geben, die aus oft Dutzenden von Plugin-Unterverzeichnissen geladen werden. Für jede dieser Ressourcen muss Apache seinen gesamten Baum durchlaufen, um nach der Konfiguration zu suchen.

Eine Analyse hat gezeigt, dass ein typisches WordPress-Setup, das eher für Websites auf Shared Hosts üblich ist, 42 separate .htaccess-Ausführungen und 249 separate Suchen nach der .htaccess-Datei beinhaltet.

Dies ist nur auf der Ebene des Webservers. Der Besucher muss noch warten, bis der PHP-Prozess den gesamten WordPress-Aufrufstapel ausgeführt hat, um die Datenbankabfrage zu erstellen und sie MySQL zu übergeben, um die Webseite zusammenzustellen und sie an den Besucher zu senden.

Module

Eine weitere Sache, die Apache populär machte, ist sein dynamisches Modulsystem.

Module – als Funktion, die es Benutzern ermöglicht, die Funktionalität von Webservern zu erweitern – gibt es sowohl in Nginx als auch im Apache. Apache ermöglicht es Benutzern, Module zu installieren, nachdem der Webserver bereits installiert und bereitgestellt wurde, und sie dann bei Bedarf zu aktivieren/deaktivieren. Debian-basierte Distributionen haben Befehle, die das Aktivieren und Deaktivieren dieser Module ermöglichen, ohne Konfigurationsdateien bearbeiten zu müssen: a2enmod und a2dismod.

Die offizielle Liste der Module, die Teil der Apache-Standarddistribution sind, findest du hier, und diese beinhalten Dinge wie Komprimierung, Verschlüsselung, Protokollierung, Umleitungen zu fortgeschritteneren Dingen wie die Bearbeitung von Anfragen und Antworten mit erweiterter Syntax.

Nginx

Nginx (auch als nginx oder NGINX geschrieben), kam 2004 auf den Markt, als es erstmals vom russischen Entwickler Igor Sysoev veröffentlicht wurde. Wie Owen Garrett, Projektmanager von Nginx, sagte:

„Nginx wurde speziell geschrieben, um die Leistungseinschränkungen von Apache-Webservern zu beseitigen.“

Der Server wurde 2002 erstmals als Skalierungswerkzeug für die Website rambler.ru erstellt. Es gibt zwei Versionen: Open Source mit BSD-Lizenz und Nginx Plus mit Unterstützung und zusätzlichen Unternehmensfunktionen.

Nach der Veröffentlichung wurde Nginx hauptsächlich für die Bereitstellung statischer Dateien und als Load-Balancer oder Reverse-Proxy vor Apache-Installationen verwendet. Mit der Entwicklung des Internets und der Notwendigkeit, jeden letzten Tropfen Geschwindigkeit und Hardware-Nutzungseffizienz damit zu bündeln, begannen immer mehr Websites, Apache durch Nginx vollständig zu ersetzen, auch dank einer ausgereifteren Software.

Im März 2019 wurde Nginx Inc. von F5 Networks für 670 Millionen US-Dollar übernommen. In diesem Moment, so berichtet Techcrunch, betreibt der Nginx-Server „375 Millionen Websites mit rund 1.500 zahlenden Kunden“.

Nach Angaben von w3techs ist der Marktanteil von Nginx stetig gestiegen, wodurch Apache nach außen gedrängt und von der Spitze entthront wurde:

Diese Daten beziehen sich auf die gesamten Webserver weltweit, aber wenn wir eine Stichprobe der obersten eine Million Websites nehmen, ist Nginx schon seit einiger Zeit dort angelangt:

Die Google Search Trends scheinen diese Tatsache ebenfalls widerzuspiegeln:

Die Netcraft-Umfrage deutet darauf hin, dass Apache im April 2019 von Nginx überholt wurde.

Nginx-Konfiguration

Nginx hat kein Konfigurationssystem wie Apache, daher wird es, obwohl es viel effizienter und schneller ist, nicht häufig bei Retail-Hosting-Providern eingesetzt. Es glänzt nicht in shared Umgebungen im Gegensatz zu Apache.

Andererseits, punktet Nginx, indem es Konfigurationen auf Verzeichnissebene nicht zulässt, ein deutlicher Vorteil gegenüber Apache. Es gibt einen Artikel im Nginx-Wiki, der die Auswirkungen auf die Leistung vergleicht:

Nginx-Module

Sein Modulsystem hebt Nginx zusätzlich als erstklassige Wahl empor. Nginx-Module müssen typischerweise beim Erstellen aktiviert werden, was bedeutet, dass es sich um ein technisch anspruchsvolleres Verfahren handelt, und das Hinzufügen von Modulen nach der Installation ist etwas komplizierter.

Im Jahr 2016, mit der Version 1.9.11, haben sich die Dinge geändert und das offizielle/verifizierte dynamische Modul-Repository ist den zahlenden Benutzern vorbehalten. Im Mai 2019 kündigten sie den Beginn der Entwicklung des Supports für QUIC und HTTP/3 an.

Die Angelegenheit des Caching: Nginx vs. Apache

Caching – wenn wir es übermäßig vereinfachen wollen – kann als Vorbereitung der Inhalte für Website-Besucher vor dem Besuch dargestellt werden, so dass man, wenn sie „an die Tür klopfen“, nicht nach den Inhalten suchen muss, nach denen sie suchen. Du hast es bereits vorbereitet und gibst es ihnen, ohne zu warten.

Wie bei Apache bestand das typische Setup von Nginx darin, zwischen Servern und Endbenutzern zu sitzen, um die Leistungseinbußen für den Rest der Infrastruktur zu verringern. In diesen Fällen kann es statische Inhalte zwischenspeichern, ohne sie jedes Mal vom geschützten, ursprünglichen Server holen zu müssen.

Wenn wir Nginx als eigenständigen Webserver verwenden – wie es bei Kinsta LXC-Containern der Fall ist – gibt es keinen solchen Bedarf. Nginx ist sehr effizient in der Bereitstellung statischer Inhalte für sich allein.

Dann gibt es noch die Frage des dynamischen Caches oder des Page-Cache. Im Szenario einer WordPress Website bedeutet dies, dass alle WordPress-Seiten, die für jede URL generiert wurden, im Speicher oder auf der Festplatte gespeichert werden.

FastCGI-Caching ist in einer Standard-Nginx-Installation nativ verfügbar. Es ist einfach, sehr leistungsfähig und eine der weniger verbreiteten Nginx-Funktionen.

Um dies mit Apache-Äquivalenten zu vergleichen, sollte man wissen, dass der Apache ein mod_cache Modul hat, das Berichten zufolge eher fehlerhaft ist und im Widerspruch zu anderen Modulen steht. Die Standard-Caching-Lösung, die mit Apache eingesetzt wird, ist also Varnish HTTP Accelerator. Obwohl Varnish die dedizierte Branchenlösung ist, geben einige aktuelle Tests Nginx Caching einen klaren Vorteil gegenüber Varnish.

Bei Kinsta verwenden wir Nginx für das dynamische WordPress-Caching, zusammen mit einem proprietären Caching-Plugin, das eine detaillierte Kontrolle über die zwischengespeicherten Seiten und die vom Kinsta-CDN zwischengespeicherten statischen Assets ermöglicht.

Bearbeitung von Anfragen: Nginx vs. Apache

Der größte Unterschied zwischen Apache und Nginx besteht in der zugrunde liegenden Architektur der Art und Weise, wie sie Anfragen behandeln.

Apache verarbeitet Anfragen mit MPM-s oder Multi-Processing-Modulen, die „für die Bindung an Netzwerkports auf der Maschine, die Annahme von Anfragen und das Senden von Kindern zur Bearbeitung der Anfragen verantwortlich sind“.

Das älteste MPM, das bis zu den Anfängen von Apache zurückreicht, ist das Prefork-Modul. Dieses Modul allein ist für die schlechte Reputation von Apache verantwortlich. In diesem Modus erzeugt Apache bei jeder Anfrage einen neuen Prozess mit einem Thread.

Dieses Modul, das mit mod_php verwendet wurde, bedeutete, dass der Apache-Server einen PHP-Interpreter in jeden einzelnen Prozess eingebettet hat, auch wenn er CSS-Dateien oder Bilder bedienen musste.

Das war ineffizient. Das Prefork-Modul wird mit Apache als Standardmodul ausgeliefert. Es beschränkt auch die Verbindungen zu HTTP/1.

In den letzten Jahren hat Apache multi-threaded worker mpm und danach das event mpm entwickelt. Beide lindern viele der Performance-Probleme von Apache. Die Umstellung auf php-fpm macht es möglich, dass Apache auch heute noch eine konkurrierende Lösung ist, und zwar ohne die Verwendung von .htaccess, aber das schadet seinem Zweck.

Nginx verwendet eine asynchrone, nicht blockierende, ereignisgesteuerte Architektur.

Um den Unterschied zu erklären: In der Linux/Unix-Welt laufen in Prozessen Programme.

Threads sind eine Teilmenge von Prozessen und es kann mehrere Threads innerhalb einer Prozessausführung geben. Betrachte dies als mehrere Registerkarten in einem Browserfenster. Auf diese Weise kann ein Programm mehrere CPUs und Multi-Core-Prozessoren mit mehreren Threads nutzen, um schneller auszuführen. Linus Torvalds legt hier die Unterschiede dar.

Kurz gesagt, Apache verwendet Prozesse für jede Verbindung (und bei Worker mpm verwendet er Threads). Mit steigendem Verkehr wird es schnell zu teuer.

Wir können uns neue Prozesse oder die Erstellung von Threads vorstellen, als zum Beispiel das Hochfahren eines Computers oder das Starten von Programmen. Selbst auf den schnellsten Computern dauert es noch einige Zeit. Wenn Websites heute Hunderte von Anfragen auf einer einzigen Seite stellen, summiert sich das schnell.

Event mpm geht in Sachen Optimierung etwas weiter, aber einige Tests zeigen, dass es Nginx nicht überlegen ist. Besonders wenn es um statische Dateien geht, wo Nginx so gut wie das Doppelte an Anfragen bedient.

Nginx verfügt idealerweise über einen Arbeitsprozess pro CPU/Kern. Der Unterschied der Nginx-Arbeitsprozesse besteht darin, dass jeder einzelne Hunderttausende von eingehenden Netzwerkverbindungen pro Arbeiter verarbeiten kann. Es ist nicht erforderlich, für jede Verbindung neue Threads oder Prozesse zu erstellen.

Dies ist der Grund, warum große Content Delivery Networks wie Cloudflare, MaxCDN und unser Partner KeyCDN – oder Websites wie Netflix – Nginx für ihr Content Delivery entscheidend finden.

Die Liste der Unternehmen, die Nginx nutzen, ist zu lang, um sie alle aufzulisten, so dass wir mit Automattic, dem privaten Unternehmen hinter WordPress.com, enden werden.

Automattic hat 2008 alle seine Load-Balancer auf Nginx für WordPress.com umgestellt (Hier kann man es nachlesen) und seinen Serverstack komplett auf Nginx migriert.

Abgleich im realen Leben

Wenn wir überprüfen wollen, was die Website in der Produktion verwendet, können wir dies in der Regel in den HTTP-Response-Headern finden. Das bedeutet, dass wir mit der rechten Maustaste auf eine Website > Inspizieren klicken müssen, in den Entwicklertools wählen wir das Netzwerkpanel aus und laden dann die Website neu. Wir werden alle Ressourcen sehen, die die Website lädt. Wenn wir eine bestimmte Ressource und deren Registerkarte Headers auswählen, sehen wir normalerweise die Serverinformationen. Wenn die Website CDN verwendet, sehen wir möglicherweise etwas wie Cloudflare in der Serverzeile oder Varnish, wenn die Website HTTP-Beschleuniger verwendet.

Dies ist ein Beispiel für eine WordPress-Website, die eine typische Shared Hosting-Konfiguration mit cPanel, Apache und PHP verwendet:

Dies ist eine Website auf Nginx:

Auf der linken Seite, wenn wir sie erweitern, können wir auch die Zeit jeder Ressource analysieren und deren Auswirkungen auf die gesamte Ladezeit der Seite sehen.

Zusammenfassung

In diesem Artikel konzentrierte ich mich auf Nginx vs. Apache und erläuterte die wichtigsten architektonischen Unterschiede, die Nginx halfen, mehr Traktion und Aufmerksamkeit innerhalb der Webserver-Arena zu erlangen. Dies sind die wichtigsten Merkmale, die ihr den Leistungsvorsprung in unserer ressourcenintensiven Branche verschaffen.

Natürlich hat nicht jeder Anwendungsfall die gleichen Prioritäten und Apache oder andere Tools wie Lighttpd, IIS, LiteSpeed, Caddy könnten gute Lösungen sein.

Bei Kinsta verwenden wir Nginx als Teil unserer leistungsoptimierten Hosting-Lösungen für WordPress und WooCommerce. Jede WordPress-Site ist in einem eigenen isolierten Container untergebracht, der über alle für ihren Betrieb erforderlichen Softwareressourcen verfügt (Nginx, Linux, PHP, MySQL). Die Ressourcen sind zu 100% privat und werden nicht zwischen anderen Websites geteilt.

Schau dir unbedingt Nginx und alle unsere Premium-Add-ons an. Schau dir auch unsere Leistungen im Anwendungs-Hosting und im Datenbank-Hosting an, um weitere Hosting-Möglichkeiten zu finden.

Tonino Jankov

Tonino ist Unternehmer, Linux- und OSS-Enthusiast, Entwickler und Ausbilder im Bereich Technik. Er hat über zehn Jahre Erfahrung in der Entwicklung und ist seit über 3 Jahren im Blockchain-Bereich tätig. Wenn er nicht gerade programmiert, schreibt er für SitePoint und Alibaba Cloud, schaut sich die neuesten Romane auf Netflix an und entdeckt neue Reiseziele.

• Twitter