Advertisement
  1. Code
  2. WordPress

Apache vs. Nginx: Vor- und Nachteile für WordPress

by
Read Time:11 minsLanguages:

German (Deutsch) translation by Valentina (you can also view the original English article)

Die Leistungsanforderungen für WordPress können von Projekt zu Projekt unterschiedlich sein, aber eines bleibt auf jeden Fall gleich - es muss schnell gehen.

Eine weitere Anforderung, die selbstverständlich ist: Sie muss wirtschaftlich sein, damit wir keine ressourcenintensiven Lösungen haben können. Die Lösungen müssen schlank, gemein und zuverlässig sein. Um das Einkommen auf Ihrer Website vollständig zu maximieren, müssen die Ausgaben für das Hosting auf ein Minimum beschränkt werden.

Wenn Sie mit viel Datenverkehr rechnen, wirkt sich die Webserverkonfiguration, auf der Sie WordPress bereitstellen, direkt auf die Leistung Ihrer Website aus und wirkt sich auf die Ladezeit und die Stabilität aus.

Bei der Auswahl Ihres Webservers haben Sie mehrere Möglichkeiten. Apache, Nginx, IIS, Caddy und Lighttpd sind beliebte Projekte. Wir werden Apache und Nginx in diesem Handbuch behandeln.

Es wird geschätzt, dass Apache Server und Nginx zusammen 50% des gesamten Webverkehrs aus dem gesamten Internet zusammen bedienen.

Wenn Sie ein Neuling in diesem Thema sind, sind Sie möglicherweise verwirrt über die beiden scheinbar identischen Zwecke der Software - die Bereitstellung von Websites. Ich hoffe, im Folgenden näher erläutern zu können, wie sich die beiden unterscheiden und wie die beiden Funktionen genutzt werden können.

Apache und Nginx sind sehr etablierte Projekte, und beide haben ihre eigenen Gründe dafür, während sie ein ähnliches identisches Ziel erreichen, Ihre WordPress-Site zu bedienen. Wenn wir uns jedoch ihre Entwürfe genauer ansehen, gibt es einen großen Unterschied in der Art und Weise, wie Verbindungen von jedem Server gehandhabt werden.

Der Unterschied

Ein wesentlicher Unterschied besteht darin, wie die Verbindungen von beiden gehandhabt werden.

Einfach ausgedrückt verwendet Apache eine Forked-Threaded-Lösung oder Keep-Alive, die eine Verbindung für jeden Benutzer offen hält.

Andererseits verwendet Nginx eine nicht blockierende Ereignisschleife, in der Verbindungen zusammengefasst werden, die über Arbeitsprozesse asynchron arbeiten.

Nginx worker process topology diagramNginx worker process topology diagramNginx worker process topology diagram

Aufgrund dieser Architektur ist das Ergebnis ein Single-Threaded-Nginx-Prozess, und es werden keine zusätzlichen Prozesse erzeugt, um jede neue Verbindung zu verarbeiten. Selbst in Zeiten hoher Last werden CPU und RAM bei diesem Ansatz nicht überlastet.

Neben der Architektur gibt es auch einige geringfügige Unterschiede und Nuancen zwischen den beiden in der Konfiguration, auf die wir später in diesem Handbuch näher eingehen werden.

Schauen wir uns zunächst die beiden Projekte an und verschaffen uns einen klaren Überblick.

Apache

  • Begonnen 1995 von Robert McCool, einem Absolventen der University of Illinois, der seit 1999 kontinuierlich unter der Apache Software Foundation entwickelt wurde.
  • Am häufigsten im Internet seit 1996 verwendet (Standard für viele Hosts, z. B. cPanel-Benutzer).
  • Verwendet ein weitgehend erweiterbares dynamisches Modul-Ladesystem.
  • Verwendet eine .htaccess-Datei zum Umschreiben von URLs.
  • Verwendet eine httpd.conf-Datei für die Serverkonfiguration mit einer XML-ähnlichen Syntax.

WordPress funktioniert sofort mit Apache. Ein PHP-Modul wie mod_php ist erforderlich, aber es ist nicht viel anderes erforderlich, um es in Gang zu bringen.

Apache ist sehr flexibel und verfügt über eine Reihe von Modulen. Im Allgemeinen wird mod_rewrite verwendet, um das Umschreiben von URLs zum Interpretieren von URLs wie categories.php?id=4 in /categories/4 bereitzustellen.

Nginx

  • Begonnen im Jahr 2002 von Igor Sysoev, einem russischen Softwareentwickler, als Lösung für das C10k-Problem - eine Herausforderung für Webserver, 10.000 gleichzeitige Verbindungen zu verarbeiten.
  • Im Jahr 2004 veröffentlicht und das Ziel als asynchrone, nicht blockierende, ereignisgesteuerte Architektur erreicht.
  • Leichtes Laufen auf minimaler Hardware bietet eine hervorragende Leistung bei statischen Inhalten.
  • Sehr reaktionsschnell unter hoher Last.
  • Verwendet eine Konfigurationsdatei nginx.conf mit einer JS-ähnlichen Syntax in geschweiften Klammern.
  • Erweiterbar mit Modulen von Drittanbietern.

Als Nachfolger von Apache hat Nginx den Vorteil, die Fallstricke und Leistungsprobleme der Parallelität zu kennen, die auftreten können, und profitiert davon mit seinem sehr schnellen asynchronen Ereignisschleifendesign.

Bei statischen Inhalten funktioniert dies sehr schnell. Bei dynamischen Inhalten wie beispielsweise PHP kann Nginx dies nicht wie Apache mit einem Modul verarbeiten. Dies ist jedoch kein Hindernis, da FastCGI verwendet wird, um dies zu erreichen. Dies funktioniert sehr gut in Verbindung mit PHP-fpm-Verbindungspools und Memcache.

WordPress-Anforderungen

  • PHP 7>
  • MySQL 5.6 oder Maria DB 10.0>
  • mod_rewrite (wenn Apache verwendet wird)
  • SSL (falls verwendet)

Sowohl Apache als auch Nginx unterstützen PHP fpm. Dies ist ein FastCGI-Manager, ein gegabelter Prozess-Manager für PHP, der verwendet werden kann, um eine sehr schnelle Antwortzeit bereitzustellen. Wenn es als Daemon auf dem Server ausgeführt wird, werden Prozesse nativ erzeugt, wenn sie benötigt werden.

Konfigurieren von PHP FPM mit Apache

Ubuntu- und Debian-Benutzer können die erforderlichen Pakete mit Eignung installieren über:

Aktivieren Sie nun das Modul in Apache:

Fügen Sie dann in der Konfigurationsdatei /etc/apache2/conf-available/php7.0-fpm.conf Folgendes hinzu:

Fügen Sie in Ihrem VirtualHost für WordPress (Standardpfad /etc/apache2/sites-available/000-default.conf) Folgendes hinzu:

Starten Sie jetzt Apache neu und Sie können loslegen

Machen Sie ein <?php phpinfo(); ?> Datei und schauen Sie in Ihrem Browser. PHP wird jetzt mit FPM bereitgestellt.

Überprüfen Sie jetzt Ihren WordPress-Blog. Bemerken Sie einen Unterschied?

Konfigurieren von PHP FPM mit Nginx

Ubuntu- und Debian-Benutzer können das Paket folgendermaßen installieren:

Jetzt müssen Sie in Ihrer Konfigurationsdatei (Standard / etc / nginx / sites-available / default) im Serverblock die FastCGI-Konfiguration wie folgt hinzufügen:

Hier verwenden wir das Snippet von Nginx, um die CGI-Parameter festzulegen und Fastcgi die Socket-Verbindung zu übergeben.

Stellen Sie als nächstes sicher, dass Sie cgi.fix_pathinfo=0 in der PHP-INI setzen, da die Standardeinstellung die Konfiguration unterbricht. Bearbeiten Sie /etc/php/7.0/fpm/php.ini und legen Sie Folgendes fest:

Jetzt können Sie die Datei speichern und PHP FPM neu laden. Tun Sie dies über:

Schließlich können wir die <? phpinfo(); ?> in einem Browser, um zu bestätigen, dass der Server jetzt PHP FPM mit Nginx verwendet.

Mod_rewrite in Nginx ausführen

Nginx verwendet keine .htaccess-Datei und hat für das Umschreiben von URLs einen viel einfacheren Ansatz.

Um Ihr WordPress-Blog mit Nginx zum Laufen zu bringen, fügen Sie dem try_files-Teil Ihrer Nginx-Konfiguration einfach Folgendes hinzu:

Wenn Sie ein Verzeichnis für Ihr WordPress-Blog verwenden, stellen Sie bitte Folgendes ein:

Starten Sie Nginx neu und die URL-Umschreibung funktioniert.

Optimale Einstellungen

Sie haben viele Möglichkeiten, WordPress durch Caching auf dem Server über Memcache, Lack und auch auf WordPress-App-Ebene mit Plugins zu optimieren, mit denen Sie einfach darauf zugreifen können.

Was Nginx Ihnen jedoch bietet, ist eine großartige Lösung für die Bereitstellung statischer Website-Inhalte mit seinem robusten und schnellen Cache für statische Inhalte.

Statischer Inhaltscache

Nginx ist sehr schnell, wenn es als statischer Inhaltscache verwendet wird, und hier zeichnet sich seine Verwendung in Bezug auf WordPress und Blog-Posts mit vielen Bildern wirklich aus. Sie können Ihr CSS, JS und Ihre Bilder über einen Nginx-Server bereitstellen, der nur für diese Anforderungen ausgeführt wird.

Es ist am besten, dies immer in einer Domain ohne Cookies zu tun, damit der Inhalt wirklich vom Browser zwischengespeichert wird (als Cookie als nicht zwischenspeicherbar). Verwenden Sie also eine Subdomain wie images.myblog.com oder static.myblog.com Ideal.

Ein Standortblock für diese statische Subdomänenkonfiguration würde folgendermaßen aussehen:

Mit open_file_cache aktivieren wir das Caching für unsere statischen Mediendateien. Wir geben die maximale Anzahl von Dateien an, die zwischengespeichert werden sollen, und wie lange mit open_file_cache max=3000 inactive=120s;

Wenn Sie das Caching projektweit einrichten möchten, fügen Sie einfach die folgenden vier Zeilen in Ihre nginx.conf-Konfigurationen ein:

Wichtig: Mit open_file_cache_errors werden die tatsächlichen 404-Fehler zwischengespeichert. Deaktivieren Sie diese Option daher besser, wenn Sie in Verbindung damit einen Load Balancer verwenden.

PHP-FPM-Verbindungspools

Es ist möglich, unterschiedliche Pools für jedes unterschiedliche WordPress zu verwenden, und Sie können dann Ressourcen für jede Site sehr genau zuweisen - bei Bedarf auch für jeden Pool unterschiedliche Benutzer und Gruppen. Die Konfiguration ist sehr flexibel.

Sie können verschiedene Konfigurationen einrichten, zum Beispiel:

In jeder der folgenden Optionen können wir eine Vielzahl von Konfigurationen wie folgt festlegen:

Hiermit können Sie die PHP-FPM-Konfigurationsoptionen wie pm.max_children angeben, Umgebungsvariablen angeben und hier die Einstellungen für Benutzername und Gruppe festlegen.

Nginx Load Balancer

Wenn Sie viel Verkehr haben, sollten Sie wahrscheinlich einen Load Balancer einrichten, der mit Ihrem PHP-Fpm-Setup verwendet werden kann.

Herkömmlicherweise möchten wir mehrere Back-End-Upstream-Server starten, auf denen alle Spiegel Ihres Blogs ausgeführt werden, und dann einen anderen Server vor sich haben, der als Load Balancer fungiert und die Last zwischen den Upstreams leitet .

Dies bedeutet, dass Sie viele Server verwenden können, um Ihr Blog gleichzeitig mit Strom zu versorgen, und die Konfiguration dafür ist relativ einfach.

Eine Beispielkonfiguration würde so aussehen. Zuerst beginnen wir mit einem Upstream-Modul:

Hier hat jedes backend1.example.com seine eigene Nginx-Konfiguration, ein Spiegelbild dessen, wie die Site war, bevor sie einen Load Balancer hatte. Nginx wählt aus, welcher Server für jede Anforderung verwendet werden soll.

Wenn eines unserer Backends über eine schnellere Festplatte verfügt, z. B. eine SSD, oder geografisch näher an Ihrer Hauptbenutzerbasis liegt, können Sie die Gewichtung folgendermaßen einstellen:

Wenn Sie der Meinung sind, dass ein Server ausfällt oder Bedenken hinsichtlich Zeitüberschreitungen besteht, gibt es auch hierfür Konfigurationsoptionen:

Mit dieser Konfiguration wird der Server nach 3 Fehlern oder einer Zeitüberschreitung von 15 Sekunden nicht mehr vom Load Balancer verwendet. Wenn Sie einen Server manuell als inaktiv markieren möchten, fügen Sie das Schlüsselwort down hinzu, z. B. server backend3.example.com down;.

Als nächstes müssen wir das über einen Proxy mit dem soeben definierten backend-Upstream an den Server übergeben:

Starten Sie jetzt Ihren Server mit service nginx restart neu und Sie führen eine Version Ihrer Site mit Lastenausgleich aus!

Zu diesem Thema gibt es auch als Referenz eine Nginx-Anleitung zum Bereitstellen von statischem Inhalt und den besten Konfigurationsoptionen. Beachten Sie beispielsweise die Verwendung von tcp_nopush und sendfile für Mp3.

Apache nach Nginx migrieren

Neben dem Lesen des Nginx-Handbuchs und dem Versuch, die Änderungen selbst vorzunehmen, können Sie das Open-Source-Tool apache2nginx verwenden, um Ihre Konfiguration von Apache nach Nginx zu übersetzen.

Befolgen Sie die Installationsschritte in der README-Datei von apache2nginx. Nach der Installation können Sie Konfigurationsdateien einfach durch Ausführen migrieren:

Sie können jetzt die Konfiguration überprüfen und in Ihrer Nginx-Installation ausprobieren. Sie werden vielleicht feststellen, dass die Übersetzung nicht perfekt war, aber sie gibt Ihnen eine Grundlage, auf der Sie beginnen können.

Abschluss

In Bezug auf Geschwindigkeit und Leistung ist Nginx die offensichtliche Wahl gegenüber Apache, aber das heißt nicht, dass Apache keinen Datenverkehr verarbeiten kann. Wenn Sie planen, bald auf die Titelseite von Reddit zu gehen, sollten Sie sich wahrscheinlich überlegen, mit Nginx und PHP-FPM eine umfassendere Lösung zu finden.

Die Migration von WordPress zu Nginx ist nicht sehr schwierig, und die zukünftige Konfiguration in Nginx ist im Vergleich zu Apache sehr einfach und leicht zugänglich.

Obwohl es nicht dieselben Module wie Apache gibt und es zunächst möglicherweise nicht bekannt ist, können Sie in den meisten Fällen einen Ersatz finden. Wenn nicht, können Sie als Fallback-Lösung den alten Server bei Bedarf jederzeit über Ihren Nginx als Proxy verwenden.

Es gibt viele Möglichkeiten, beide Server zu konfigurieren, sodass fast immer eine gute Lösung für alle Anforderungen gefunden werden kann. Derzeit scheint Apache aufgrund des mitgelieferten EasyApache-Setup-Tools immer die Standardauswahl für die weit verbreitete Hosting-Software cPanel zu sein.

In Zukunft werden möglicherweise mehr Hosts Nginx cPanel-Tools wie Engintron einsetzen, die Nginx auch auf cPanel bereitstellen.

Wenn Sie vorerst auf ein Nginx-basiertes WordPress umsteigen möchten, müssen Sie ein Linux-VPN bei DigitalOcean, AWS oder einem anderen Hosting-Anbieter einrichten.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.