Die Wahl des richtigen Webservers ist eine wichtige Entscheidung bei der Entwicklung eines neuen Shopware 6 Shops. Apache und Nginx sind die beiden führenden HTTP-Server und kommen in vielen unterschiedlichen Projekten zum Einsatz. Beide Server bieten einzigartige Vorteile und Herausforderungen, die bei der Auswahl des passenden Servers berücksichtigt werden sollten. Um zu verstehen, welche dieser beiden Optionen besser zu Deinen Anforderungen passt, lohnt sich ein genauerer Blick auf die Unterschiede und Einsatzmöglichkeiten von Apache und Nginx.
tl;dr;
Wenn Du Dich nicht allzu sehr mit den genauen Hintergründen beschäftigen willst, findest Du unten am Ende der Seite eine Zusammenfassung mit meiner persönlichen Empfehlung 😃
Was ist ein Apache oder Nginx überhaupt?
Gerade wenn man bisher noch nicht allzu viel Erfahrung mit der Einrichtung eines Shopware Shops gesammelt hat, stellt man sich die Frage schnell.
Beide Tools sind sogenannte “HTTP-Server”. Ein HTTP-Server ist eine Software, die Anfragen von Webbrowsern entgegennimmt und daraufhin Webseiten, Bilder oder Dateien bereitstellt.
Wenn ein Kunde z.B. Deinen Shop besucht, tippt er die URL des Shops ein oder klickt auf einen Link bei Google. Der Browser schickt hierbei über die Domain und die dahinterliegende IP eine Anfrage an den Server. Ist dort ein HTTP-Server installiert, reagiert dieser auf die Anfrage und verarbeitet sie intern. Auf einem Server, der einen Shopware 6 Shop hostet, verarbeitet PHP die Anfrage und liefert in unserem Fall die Startseite des Shops als fertiges HTML zurück, welches der HTTP-Server am Ende dem Kunden anzeigt.
Vereinfacht gesagt nehmen Apache oder Nginx also die Anfragen an unseren Server entgegen, geben sie an PHP weiter und zeigen dem Kunden das HTML unseres Shops an. Wie Du PHP optimieren kannst, erfährst du hier.
Wie sind Apache & Nginx entstanden
Apache
Der Apache HTTP Server wurde 1995 von Robert McCool entwickelt und seit 1999 unter der Leitung der Apache Software Foundation weitergeführt. Da der HTTP-Webserver das ursprüngliche Projekt der Foundation ist und bei Weitem deren bekannteste Software darstellt, wird er oft einfach nur „Apache“ genannt.
Der Apache-Webserver war von mindestens 1996 bis 2016 der beliebteste Server im Internet. Dank dieser Beliebtheit profitiert Apache von einer umfangreichen Dokumentation und integrierter Unterstützung durch andere Softwareprojekte.
Administrator entscheiden sich oft für Apache aufgrund seiner Flexibilität, Leistungsstärke und nahezu universellen Unterstützung. Er ist durch ein dynamisch ladbares Modulsystem erweiterbar und kann viele Skriptsprachen wie PHP direkt ausführen, ohne zusätzliche Software zu benötigen.
Nginx
Im Jahr 2002 begann Igor Sysoev mit der Entwicklung von Nginx als Antwort auf das sogenannte C10K-Problem, das eine große Herausforderung für Webserver darstellte: die Fähigkeit, zehntausend gleichzeitige Verbindungen zu handhaben. Nginx wurde 2004 veröffentlicht und erreichte dieses Ziel durch eine asynchrone, ereignisgesteuerte Architektur.
Inzwischen hat Nginx Apache in der Beliebtheit überholt, da er durch seine geringe Speicherauslastung und die einfache Skalierbarkeit auf minimaler Hardware überzeugt. Nginx ist besonders gut darin, statische Inhalte schnell bereitzustellen, verfügt über ein robustes Modulsystem und kann bei Bedarf dynamische Anfragen an andere Software weiterleiten.
Administrator wählen Nginx häufig aufgrund seiner Ressourceneffizienz und Reaktionsfähigkeit unter Last sowie der klaren Konfigurationssyntax.
Wie gehen Apache & Nginx unter der Haube mit Verbindungen um?
Ein zentraler Unterschied zwischen Apache und Nginx liegt in der Art und Weise, wie sie Verbindungen und Netzwerkverkehr handhaben. Dies ist vermutlich der bedeutendste Unterschied in ihrem Verhalten unter hoher Last.
Apache
Apache bietet verschiedene sogenannte “Multi-Processing-Module” (MPMs) an, die festlegen, wie Anfragen verarbeitet werden:
- mpm_prefork: Dieses Modul startet für jede Anfrage einen separaten Prozess mit nur einem Thread. Solange die Anzahl der Anfragen unter der Prozessanzahl bleibt, ist das Modul schnell. Bei zu vielen Anfragen sinkt die Leistung jedoch rapide, da jeder Prozess viel RAM verbraucht und das Modul daher schwer skalierbar ist. Es eignet sich jedoch gut für Anwendungen wie PHP, das oft nicht thread-sicher ist, da es so sicher mit dem mod_php-Modul arbeitet.
- mpm_worker: Dieses Modul startet Prozesse, die jeweils mehrere Threads verwalten können, wobei jeder Thread eine Verbindung abwickelt. Da Threads effizienter als Prozesse sind, skaliert dieses Modul besser als
mpm_prefork. Neue Verbindungen können direkt auf freie Threads zugreifen und müssen nicht auf freie Prozesse warten. - mpm_event: Ähnlich dem
worker-Modul, ist jedoch speziell auf „keep-alive“-Verbindungen optimiert. Währendmpm_worker-Verbindungen einen Thread belegen, auch wenn keine aktive Anfrage erfolgt, widmetmpm_eventseparate Threads für „keep-alive“-Verbindungen und verteilt aktive Anfragen auf andere Threads. Dies verhindert, dass „keep-alive“-Verbindungen die Leistung beeinträchtigen, und sorgt für eine schnellere Verarbeitung.
Apache benutzt im Standard mpm_prefork. In meinem eigenem Shop hatte ich dieses module auch Anfangs benutzt. Da prefork aber kein http2 unterstützt, habe ich auf mpm_event mit PHP FPM gewechselt. Das empfehle ich auch für jeden Shopware 6 Shop, der Apache verwenden möchte.
Nginx
Nginx wurde nach Apache entwickelt und ging von Anfang an auf die Skalierungsprobleme vieler Websites ein. Daher basiert Nginx auf einem asynchronen, nicht-blockierenden, ereignisgesteuerten Algorithmus zur Verbindungsverarbeitung.
Nginx startet sogenannte Worker-Prozesse, die jeweils Tausende von Verbindungen verwalten können. Dies gelingt durch einen schnellen Looping-Mechanismus, der kontinuierlich auf Ereignisse prüft und sie verarbeitet. Durch die Entkopplung der eigentlichen Arbeitsprozesse von den Verbindungen kümmert sich jeder Worker nur dann um eine Verbindung, wenn ein neues Ereignis ausgelöst wird.
Alle Verbindungen, die der Worker verwaltet, werden in der Ereignisschleife verarbeitet. Innerhalb der Schleife werden die Ereignisse asynchron bearbeitet, was eine nicht-blockierende Arbeitsweise ermöglicht. Wenn eine Verbindung geschlossen wird, wird sie aus der Schleife entfernt.
Diese Art der Verbindungsverarbeitung erlaubt Nginx, mit begrenzten Ressourcen zu skalieren. Da der Server single-threaded ist und keine neuen Prozesse für jede Verbindung startet, bleiben Speicher- und CPU-Verbrauch auch bei hoher Last relativ stabil.
Statische vs dynamische Inhalte
Apache
Apache-Server können statische Inhalte mithilfe herkömmlicher dateibasierter Methoden bereitstellen, wobei die Leistung dieser Prozesse hauptsächlich von den zuvor beschriebenen MPM-Methoden abhängt.
Für dynamische Inhalte kann Apache einen Interpreter der entsprechenden Programmiersprache direkt in jede Worker-Instanz einbetten. Dadurch kann der Server dynamische Inhalte selbst ausführen, ohne auf externe Komponenten angewiesen zu sein. Diese dynamischen Prozessoren lassen sich über dynamisch ladbare Module aktivieren.
Apache’s Fähigkeit, dynamische Inhalte intern zu verarbeiten, trug erheblich zur Popularität der LAMP-Architektur (Linux-Apache-MySQL-PHP) bei, da der Webserver PHP-Code direkt ausführen kann.
Nginx
Nginx kann dynamische Inhalte nicht selbstständig verarbeiten. Um PHP- oder andere dynamische Anfragen zu bearbeiten, muss Nginx die Anfrage zur Ausführung an eine externe Bibliothek weiterleiten und auf das Ergebnis warten, das dann an den Client zurückgegeben wird.
Diese Anfragen werden mithilfe eines der Protokolle, die Nginx unterstützt (z. B. http, FastCGI, SCGI, uWSGI, memcache), an die externe Bibliothek übertragen. In der Praxis ist PHP-FPM, eine FastCGI-Implementierung, eine gängige Lösung, aber Nginx ist nicht fest mit einer bestimmten Sprache verbunden.
Dieser Ansatz hat auch Vorteile: Da der dynamische Interpreter nicht in den Worker-Prozess eingebettet ist, tritt sein Overhead nur bei dynamischen Inhalten auf. Statische Inhalte können direkt bedient werden, und der Interpreter wird nur bei Bedarf angefragt.
Verteilte vs. Zentrale Konfiguration
Apache und Nginx unterscheiden sich deutlich darin, wie sie Konfigurationsanpassungen auf Verzeichnisebene ermöglichen.
Apache
Apache bietet die Möglichkeit, zusätzliche Konfigurationen auf Verzeichnisebene zu erlauben, indem es versteckte .htaccess-Dateien in den Inhaltsverzeichnissen überprüft und interpretiert.
Da diese Dateien in den Inhaltsverzeichnissen selbst liegen, überprüft Apache beim Verarbeiten einer Anfrage jedes Verzeichnis im Pfad zur angeforderten Datei auf eine .htaccess-Datei und wendet gefundene Anweisungen an. Dies erlaubt eine dezentrale Konfiguration des Webservers, die oft für URL-Weiterleitungen, Zugriffs- und Authentifizierungsrichtlinien oder Caching-Strategien genutzt wird.
Während sich diese Konfigurationen auch in der zentralen Apache-Konfigurationsdatei vornehmen lassen, haben .htaccess-Dateien zwei wesentliche Vorteile: Erstens werden Änderungen sofort umgesetzt, ohne den Server neu laden zu müssen. Zweitens ermöglicht es, nicht privilegierten Nutzern Kontrolle über bestimmte Aspekte ihrer Webinhalte zu geben, ohne ihnen Zugriff auf die gesamte Konfiguration zu gewähren.
Dies ist besonders hilfreich für Websoftware wie Content-Management-Systeme oder bei Shared Hosting, wo die Hauptkonfiguration vom Anbieter verwaltet wird, während Kunden nur ihre spezifischen Verzeichnisse steuern.
Nginx
Nginx interpretiert keine .htaccess-Dateien und bietet keine Mechanismen zur Konfiguration auf Verzeichnisebene außerhalb der zentralen Konfigurationsdatei. Während Apache ursprünglich für eine Zeit entwickelt wurde, in der heterogene Webanwendungen nebeneinander auf einem Server liefen und Berechtigungen delegiert werden mussten, wurde Nginx in einer Ära entwickelt, in der Webanwendungen eher containerisiert und mit eigenen Netzwerkkonfigurationen ausgestattet sind, was diesen Bedarf reduziert. Das kann in einigen Situationen weniger flexibel sein als das Apache-Modell, bietet jedoch Vorteile.
Der bedeutendste Vorteil gegenüber der .htaccess-Struktur ist die gesteigerte Leistung. Bei einem typischen Apache-Setup, das .htaccess-Dateien in jedem Verzeichnis erlaubt, sucht der Server bei jeder Anfrage nach diesen Dateien in allen übergeordneten Verzeichnissen bis zur angeforderten Datei. Durch das Weglassen von Verzeichnis-Overrides kann Nginx Anfragen schneller bedienen, da nur ein einziger Verzeichnisaufruf und Dateizugriff pro Anfrage notwendig ist.
Ein weiterer Vorteil betrifft die Sicherheit: Durch verteilte Konfigurationszugriffe wird die Verantwortung für Sicherheit auch an individuelle Nutzer übertragen, die möglicherweise nicht zuverlässig damit umgehen können. In Apache kann die Interpretation von .htaccess-Dateien bei Bedarf ebenfalls deaktiviert werden, um diese Bedenken auszuräumen.
Datei- vs. URI-basierte Interpretation
Ein wesentlicher Unterschied zwischen Apache und Nginx liegt darin, wie die beiden Server Anfragen interpretieren und diese auf tatsächliche Ressourcen im System abbilden.
Apache
Apache interpretiert Anfragen entweder als Dateien im Dateisystem oder als abstrakte URI-Standorte. Für Dateisystempfade nutzt Apache <Directory>– und <Files>-Blöcke, für URIs <Location>-Blöcke.
Standardmäßig behandelt Apache Anfragen als Dateisystem-Ressourcen. Es kombiniert den Document Root mit dem Anfragepfad, um die gewünschte Datei zu finden, und stellt das Dateisystem als Dokumentbaum dar.
Wenn eine Anfrage nicht direkt auf das Dateisystem passt, bietet Apache Alternativen wie die Alias-Direktive für alternative Orte. <Location>-Blöcke ermöglichen es, URI-Pfade zu konfigurieren. Apache bevorzugt jedoch Dateisystempfade und rät davon ab, URI-Blöcke für Zugriffsbeschränkungen zu nutzen, wenn die Anfrage das Dateisystem widerspiegelt.
Nginx
Nginx wurde als Web- und Proxy-Server entwickelt. Diese duale Rolle erfordert eine Architektur, die primär mit URIs arbeitet und nur bei Bedarf auf das Dateisystem zugreift.
Dies zeigt sich in der Struktur und Interpretation der Nginx-Konfigurationsdateien. Nginx bietet keine Möglichkeit, Konfigurationen für ein bestimmtes Dateisystemverzeichnis anzugeben; stattdessen wird die URI selbst interpretiert.
Die Hauptkonfigurationsblöcke von Nginx sind server– und location-Blöcke. Der server-Block interpretiert den angefragten Host, während location-Blöcke für das URI-Teil nach Host und Port zuständig sind. An dieser Stelle wird die Anfrage als URI, nicht als Dateisystemposition interpretiert.
Für statische Dateien müssen alle Anfragen letztlich auf eine Position im Dateisystem abgebildet werden. Nginx wählt dafür die entsprechenden server– und location-Blöcke und kombiniert das Document Root mit der URI, um die angeforderte Datei bereitzustellen.
Durch die primäre Verarbeitung von Anfragen als URIs anstatt als Dateisystempfade kann Nginx besser in den Rollen als Web-, Mail- und Proxy-Server agieren. Nginx konfiguriert das Antwortverhalten auf verschiedene Anfrage-Muster, prüft das Dateisystem jedoch erst, wenn es die Anfrage tatsächlich bedient. Dies erklärt, warum Nginx keine .htaccess-Dateien implementiert.
Apache und Nginx gemeinsam nutzen
Nach einem Blick auf die Vorteile und Einschränkungen von Apache und Nginx kann eine Kombination beider Server sinnvoll sein, um die jeweiligen Stärken zu nutzen.
Die gängige Konfiguration für diese Kombination ist es, Nginx als Reverse Proxy vor Apache zu schalten. Dadurch kann Nginx alle Anfragen von Clients entgegennehmen und seine schnelle Verarbeitung sowie die Fähigkeit, viele Verbindungen gleichzeitig zu handhaben, optimal nutzen.
Für statische Inhalte, in denen Nginx besonders leistungsstark ist, werden die Dateien direkt und schnell an den Client gesendet. Für dynamische Inhalte, wie z. B. PHP-Dateien, leitet Nginx die Anfrage an Apache weiter, welcher die Inhalte verarbeitet und die gerenderte Seite zurückgibt. Nginx sendet die Antwort dann an den Client.
Diese Kombination funktioniert gut, da Nginx wie eine „Sortiermaschine“ agiert: Es übernimmt alle Anfragen, die es selbstständig bedienen kann, und gibt die restlichen an Apache weiter. So kann die Belastung von Apache reduziert werden, da nur die Anfragen weitergeleitet werden, die Nginx nicht verarbeiten kann. Dies verringert mögliche Engpässe, die auftreten, wenn ein Apache-Prozess blockiert ist.
Zusätzlich ermöglicht diese Konfiguration eine horizontale Skalierung durch das Hinzufügen weiterer Backend-Server. Nginx kann so konfiguriert werden, dass es Anfragen an mehrere Server weiterleitet, was die Leistung weiter steigern kann.
Fazit
Für kleine Shops ist es eigentlich fast schon egal, welchen HTTP-Server man verwendet.
Für Shopware Shops mit mittel bis hohem Traffic würde ich in den meisten Fällen Nginx empfehlen. Nginx ist speziell dafür entwickelt worden, eine große Anzahl gleichzeitiger Verbindungen effizient zu verarbeiten. Dank seiner asynchronen, ereignisgesteuerten Architektur kann Nginx Ressourcen besser nutzen und bleibt auch bei hoher Last stabil, was zu geringeren Serveranforderungen und kürzeren Ladezeiten führt.
Nginx eignet sich besonders gut für das schnelle Ausliefern statischer Inhalte. Für dynamische Inhalte kann Nginx als Reverse Proxy vor einem Apache-Server eingesetzt werden, der die dynamischen Anfragen bearbeitet. Diese Kombination ermöglicht eine hohe Performance, da Nginx den Großteil der Anfragen übernimmt und nur dynamische Inhalte an Apache weiterleitet.
In einigen Fällen könnte auch ein Einsatz von Varnish als HTTP-Cache sinnvoll sein, um im Shop gecachte Seiten ohne Apache/ PHP direkt zurückzugeben, wodurch entsprechend etwas Last gespart wird.
Zusammengefasst: Für eine Seite mit hohem Traffic bietet Nginx allein oder in Kombination mit Apache oft die beste Performance und Skalierbarkeit.
