PHP-7-Performance mit NGINX maximieren, Teil 1: Webbereitstellung und Caching

NGINX | 26. Februar 2016

Einführung – So wird NGINX mit PHP verwendet

PHP ist die beliebteste Methode zur Erstellung einer serverseitigen Webanwendung und hat einen Marktanteil von etwa 80 %. (ASP.net folgt mit großem Abstand auf Platz zwei, Java mit noch größerem Abstand auf Platz drei.)

Das PHP-Universum umfasst eine Vielzahl von PHP-Frameworks; zu den beliebtesten gehören Laravel, Phalcon und Symfony 2. PHP bildet außerdem die Grundlage für beliebte Content-Management-Systeme (CMS) wie WordPress und Drupal. (Die neueste Drupal-Version, Drupal 8, bietet eine umfassende Symfony 2-Integration.

Nun veröffentlicht das PHP-Team eine neue Version, PHP 7 – mehr als ein Jahrzehnt nach der Einführung von PHP 5. In dieser Zeit sind sowohl die Nutzung des Internets als auch die Anforderungen an Websites exponentiell gestiegen. PHP hat zu diesem rasanten Wachstum beigetragen – doch gerade das Wachstum, das PHP ermöglicht hat, macht auch seine Grenzen deutlich.

PHP gilt gemeinhin als leistungsstark und flexibel, ist jedoch anfällig für Performanceprobleme. PHP-basierte Websites können bereits nach wenigen Verdopplungen der Zugriffszahlen schnell „an ihre Grenzen stoßen“. Gerade wenn eine Website beginnt, ihre geschäftlichen oder betrieblichen Ziele zu erreichen, stürzt sie bei jedem Anstieg des Datenverkehrs ab.

Bei Tausenden und Abertausenden PHP-basierter Anwendungen haben bereits einige relativ einfache Änderungen ausgereicht, um die Leistung zu verbessern. Dazu gehören das Caching mit Tools wie memcached, die Optimierung von Datenbanken sowie Reverse-Proxy- und Lastverteilungsfunktionen mit NGINX Open Source und NGINX Plus. NGINX hat die Reaktionsfähigkeit von Anwendungen erheblich verbessert und ermöglicht eine Steigerung der Benutzer- und Zugriffszahlen um Größenordnungen.

Dieser Blogbeitrag ist der erste Teil einer zweiteiligen Reihe zur Maximierung der Performance Ihrer Websites, die PHP 7 verwenden. Hier konzentrieren wir uns auf das Upgrade auf PHP 7, den Einsatz von NGINX Open Source oder NGINX Plus als Webserver-Software, das Umschreiben von URLs (notwendig, damit Anfragen korrekt verarbeitet werden), das Caching statischer Dateien und das Caching dynamischer Dateien (auch als Anwendungs-Caching oder Microcaching bezeichnet).

Im nächsten Blogbeitrag konzentrieren wir uns auf Maßnahmen, die Sie mit zusätzlichen Servern umsetzen können: das Hinzufügen eines Reverse-Proxy-Servers, den Umstieg auf mehrere Anwendungsserver, die Lastverteilung auf mehrere Server, die Unterstützung persistenter Sitzungen bei der Lastverteilung sowie die Terminierung von Sicherheitsprotokollen wie SSL/TLS und dem zugehörigen HTTP/2-Protokoll.

Warum PHP an seine Grenzen stößt

Warum stoßen PHP-Anwendungen an ihre Grenzen? Aus demselben Grund, aus dem jede Anwendungsserversoftware an ihre Grenzen stößt. Wenn eine Benutzeranfrage eingeht, müssen PHP und die Webserversoftware, auf der es ausgeführt wird, mehrere Aufgaben erledigen:

Die Anfrage entschlüsseln. Zunächst muss die Webserver-Software und anschließend PHP Prozesse starten, um die Anfrage zu empfangen, zu entschlüsseln und zu bearbeiten. Apache HTTP Server beispielsweise weist jeder Datenanfrage Ressourcen zu, unabhängig davon, ob sie einfach (Abrufen einer JPEG-Datei) oder komplex (Verarbeiten verschachtelter CSS-Anfragen) ist. All dies kostet Zeit und Systemressourcen und erfordert die Zuweisung von Arbeitsspeicher – die durchaus beträchtlich sein kann, wenn das Betriebssystem, PHP oder beide eine Reihe von Bibliotheken laden müssen, bevor die Verarbeitung der Anfrage überhaupt beginnen kann.
Unterstützende Protokolle verarbeiten. Wenn Sie SSL/TLS und/oder HTTP/2 verwenden, muss Ihre Webserver-Software Anfragen entschlüsseln, was unter Umständen zeitaufwendig ist.
Anfrage verarbeiten. PHP muss die zur Verarbeitung der Anfrage erforderlichen Ressourcen zusammenführen. Dies kann mehrere Datenbankabfragen, Aufrufe externer Dienste über das Internet und komplexe interne Verarbeitungsvorgänge erfordern.
Auf die Anfrage antworten. PHP muss die Ergebnisse an die Webserver-Software zurückgeben, damit sie als HTTP-Antwort an den Anfragenden übermittelt werden können. Beachten Sie, dass sowohl die Webserver-Software als auch PHP für jede Anfrage einen aktiven, dedizierten Thread ausführen – vom ersten Empfang bis zur abschließenden Bestätigung.

Das ist eine enorme Belastung, die ein physischer Server, eine virtuelle Maschine oder eine Cloud-Serverinstanz bei jeder Anfrage bewältigen muss. Sobald der physische Arbeitsspeicher des Servers – unabhängig davon, ob es sich um einen physischen oder virtuellen Server handelt – erschöpft ist, bricht die Leistung meist ein. Der Server beginnt dann, laufende Sitzungen auf die Festplatte auszulagern, während neue Anfragen eingehen. Auch das Warten auf die Bearbeitung von Dateianfragen führt zu Wartezuständen, die das Auslagern zusätzlich verstärken. Ab einem (sehr schnell erreichten) Punkt überlasten Auslagerungsvorgänge und Datenanfragen die Verarbeitung, und die Leistung gerät in eine Abwärtsspirale, die bei frustrierten Benutzern zu langen Wartezeiten oder sogar zum vollständigen Abbruch der Sitzung führt.

Behebung von Leistungsproblemen

Die Performance-Hürden von PHP lassen sich durchaus überwinden. Dazu sind mehrere sich ergänzende Maßnahmen erforderlich, die miteinander kombiniert werden können. Im Wesentlichen gehören dazu:

Das Problem mit mehr Hardware lösen. Mehr Arbeitsspeicher, mehr Arbeitsspeicher, schnellere Festplatten, separate Datenbankserver, ein Content Delivery Network, eine höhere Durchsatzkapazität und andere technische Maßnahmen sind eine schnelle, aber unsaubere Lösung für Performanceprobleme. Diese Lösungen können die Verfügbarkeit aufrechterhalten oder eine lineare Skalierung der Performance ermöglichen.
Verbesserung von PHP und Anwendungscode. Neue PHP-Versionen, neue Frameworks und optimierter Anwendungscode können viel bewirken. So lässt sich die Leistung verdoppeln oder sogar vervierfachen, ohne zusätzliche Ausgaben für neue Hardware.
Verbesserte Serversoftware. Die meisten Webserver und PHP weisen jeder aktuell geöffneten Anfrage dedizierte Ressourcen zu. Die NGINX-Serversoftware verarbeitet eingehende Anfragen, ohne Ressourcen zu blockieren, und minimiert so den Ressourcenbedarf des Servers.
Implementierung mit mehreren Servern. Sie können einen Reverse-Proxy-Server einsetzen, der Internetanfragen verarbeitet und sie auf einen oder mehrere Anwendungsserver verteilt (Lastenausgleich). Der Reverse-Proxy-Server kann außerdem das Datei-Caching, die Terminierung von Protokollen wie SSL/TLS und HTTP/2 sowie die Verwaltung mehrerer Anwendungsserver übernehmen. Selbst bei nur einem Anwendungsserver wird dadurch ein erheblicher Teil seiner Arbeitslast ausgelagert. Der Lastenausgleich stellt sicher, dass kein Server mit mehr als seinem Anteil an der Last überlastet wird, wenn weitere Server hinzukommen.

Sie müssen diese Schritte nicht in einer bestimmten Reihenfolge umsetzen. Selbst wenn Sie beispielsweise Apache als Webserver beibehalten und Ihren Anwendungsserver nicht auf PHP 7 aktualisieren, verbessert bereits der Einsatz von NGINX als Reverse-Proxy „vor“ Ihren vorhandenen Servern die Leistung und ermöglicht es Ihnen, mehrere Anwendungsserver parallel zu betreiben.

Wie auch immer Sie dabei vorgehen, entscheidend ist: Sie können die Leistung um ein Vielfaches und die Kapazität sogar um eine Größenordnung steigern, ohne Ihren bestehenden Anwendungscode wesentlich ändern zu müssen. Lesen Sie weiter und erfahren Sie, wie andere diese außergewöhnlichen Leistungssteigerungen bereits erzielt haben oder gerade dabei sind, sie zu erreichen.

Hinweis: Es gibt eine Optimierung für Umgebungen mit mehreren Servern, auf die wir in diesen Blogbeiträgen nicht näher eingehen werden. Ein separater Datenbankserver und ein Content Delivery Network (CDN) können Ihren Anwendungsserver entlasten und die Leistung erheblich verbessern. Derartige Änderungen sind unabhängig von den hier beschriebenen Verbesserungen an Anwendung und Implementierung und können parallel dazu vorgenommen werden.

Tipp 1 – Upgrade auf PHP 7

Der Hauptgrund, lieber früher als später auf PHP 7 zu aktualisieren, ist einfach: die Anwendungsgeschwindigkeit (die insbesondere durch Speichereinsparungen ermöglicht wird). PHP 7 soll doppelt so schnell wie frühere PHP-Versionen sein und deutlich weniger Speicher benötigen. (In beiden Punkten können Ihre Ergebnisse natürlich abweichen.)

Die Antwortzeit ist für Webanwendungen schlichtweg entscheidend. Eine schnellere Webanwendung, die zudem weniger Arbeitsspeicher benötigt und dadurch die Wahrscheinlichkeit von Speicherauslagerungen und daraus resultierenden Leistungsproblemen verringert, bewirkt drei Dinge:

Macht die Nutzer zufriedener und erhöht die Wahrscheinlichkeit, dass sie Ihre Website besuchen und dort Aufgaben erledigen, etwa Artikel lesen, Produktinformationen abrufen, ein Sammeltaxi rufen, ein freies Zimmer mieten oder etwas kaufen. Also genau das tun, wofür Sie die Website oder App ursprünglich erstellt haben.
Ermöglicht es einem bestimmten Server, mehr Benutzer zu unterstützen, ohne Gefahr zu laufen, dass er durch zusätzliche Benutzer langsamer wird oder sogar ganz zusammenbricht. Den Untergang hinauszuzögern, ist immer eine gute Sache.
Macht Ihren Server weniger anfällig für Hackerangriffe, die ihn durch Überlastung außer Betrieb setzen sollen. Heutzutage wird jeder angegriffen, doch schwache Ziele werden häufiger und aggressiver attackiert. Eine geringere Anfälligkeit kann daher um ein Vielfaches besser sein als eine höhere.

All dies sind hervorragende Gründe für ein Upgrade; zusammengenommen sprechen sie nahezu überwältigend dafür. Und „auf die neueste Version aktualisieren“ ist bei vielen Problemen immer die erste Empfehlung zur Behebung, selbst wenn der Leistungsvorteil nicht so eindeutig ist. Warum führt dann nicht jeder sofort ein Upgrade durch?

Updates laut xkcd

Ganz einfach: Menschen ändern nur ungern alten Code, und das aus gutem Grund. Wenn eine alte Anwendung gut genug funktioniert und Entwickler mit der Entwicklung neuer Anwendungen bessere Ergebnisse erzielen als mit der Aktualisierung alter, kann die alte Anwendung sehr lange unverändert bestehen bleiben. (Im zweiten Blogbeitrag dieser Reihe erfahren Sie, wie Sie mit NGINX die Leistung Ihrer Anwendung verbessern können, ohne Änderungen an Ihrem aktuellen Webserver oder Ihrer Anwendung vorzunehmen.)

Effizienter ist es jedoch, sofern irgend möglich, die Leistungsoptimierung mit einem Upgrade auf PHP 7 zu beginnen. Fangen Sie damit aber erst an, wenn Sie genügend Zeit haben, das Upgrade abzuschließen – insbesondere ohne bei den Tests Abstriche zu machen.

Sehen wir uns an, was für ein Upgrade auf PHP 7 erforderlich ist:

Änderungen bei der Auswertung von Ausdrücken. Möglicherweise müssen Sie die Schreibweise einiger Ausdrücke ändern, damit sie in PHP 7 korrekt ausgewertet werden. (Oder, wenn Sie besonders vorsichtig vorgehen und nicht alle Ihre PHP-Server gleichzeitig aktualisieren, damit sie sowohl in PHP 5.6 als auch in PHP 7 korrekt ausgewertet werden.) Wenn Sie Variablenvariablen oder variable Eigenschaften verwenden, müssen Sie den Code überarbeiten, damit diese in beiden PHP-Versionen auf dieselbe Weise ausgewertet werden.
Syntaxänderungen. PHP 7 unterstützt weder ASP- noch Script-Tags. Eine switch-Anweisung darf nicht mehrere default-Fälle enthalten. (Wir lassen die Kontroverse um switch im Vergleich zu if-then-else außen vor.)
Entfernung veralteter Funktionen. Allerlei Dinge, die in verschiedenen 5.x-Versionen von PHP als veraltet eingestuft wurden, sind jetzt toter als ein toter Papagei. Sie funktionieren in PHP 7 schlichtweg nicht mehr. Wenn sie in Ihrem Code enthalten sind und Sie versuchen, sie alle zu entfernen, dabei aber etwas übersehen, wird die Funktionalität Ihres Warenkorb-Codes garantiert am Abend vor dem Cyber Monday um 23:59 Uhr ausfallen.
Neue Funktionen. PHP 7 bietet eine Reihe neuer Funktionen, die für alle verlockend sind, die alten Code aktualisieren. Seien Sie jedoch vorsichtig, wenn Sie im Zuge einer Codebereinigung neue Funktionen hinzufügen. Neue Funktionen sind oft großartig – sonst wären sie nicht hinzugefügt worden –, aber sie ziehen auch Fehler (Ihre eigenen und die anderer) sowie künftige Überarbeitungen im Zuge weiterer PHP-Upgrades geradezu an.
Allgemeine Codeüberprüfung. Jedes Mal, wenn Sie Code bearbeiten – ja, sogar wenn Sie nur eine Codedatei öffnen und sich nicht sicher sind, ob Sie etwas daran geändert haben –, sollten Sie wirklich den gesamten Inhalt überprüfen, insbesondere alles, was Sie geändert haben.
Tests. Alles muss jederzeit getestet werden. Wenn Sie Änderungen vornehmen, müssen Sie alles erneut testen, und selbst dann ist nicht gewährleistet, dass Sie jeden Fehler finden. Eine gut implementierte DevOps-Umgebung kann diese Tests relativ einfach machen, doch bislang kommen nur wenige von uns in den Genuss dieses Idealzustands.

Dieser Blogbeitrag von Engine Yard enthält gute Beispiele für die meisten dieser Probleme.

Wenn Sie sich für ein Upgrade auf PHP 7 entscheiden, sollten Sie eine umfassende Leistungsprüfung und Überarbeitung Ihres Codes oder zumindest seiner kritischen Funktionen in Betracht ziehen und dabei die neuen Funktionen von PHP 7 nutzen. Es gibt keinen besseren Weg für Sie und Ihr Team, Ihre Kenntnisse zu erweitern. Die Änderungen, die Sie heute vornehmen, überprüfen und testen, werden Ihnen wahrscheinlich noch viele Jahre zugutekommen. Außerdem profitieren Sie so optimal von den anderen Leistungsempfehlungen in diesem Blogbeitrag, denn optimierter Code entfaltet sein Potenzial besonders gut in einer optimierten Umgebung.

Obwohl Websites NGINX häufig einsetzen, um eine bessere Performance zu erzielen, ohne den Anwendungscode anzutasten, empfehlen wir Ihnen daher, die Zügel in die Hand zu nehmen und entschlossen voranzugehen. Für die Umstellung finden Sie zahlreiche Hilfsangebote – oder Sie krempeln einfach die Ärmel hoch und nehmen sie selbst vor. Auf der offiziellen PHP-Website finden Sie einen Migrationsleitfaden für PHP 7 und bei O’Reilly ein Praxisbuch zum Upgrade auf PHP 7.

Tipp 2 – Entscheiden Sie sich für NGINX Open Source oder NGINX Plus

NGINX ist die Software, auf der mehr als 140 Millionen Websites laufen, darunter die Hälfte der 10.000 meistbesuchten Websites. (Bei diesen Messungen wird bei Websites mit einem einzelnen Server der Webserver und bei Websites mit mehreren Servern der Reverse-Proxy-Server erfasst.) Als Webserver bieten sowohl NGINX Open Source als auch NGINX Plus eine sofortige Leistungssteigerung – in einigen Fällen, in denen ein Server mit anderer Software überlastet war und durch ständiges Auslagern kaum noch arbeitsfähig war, sogar um das bis zu Zehnfache. Als Reverse-Proxy-Server ermöglichen beide den Einsatz mehrerer dedizierter Server, um eine Bereitstellung so weit wie nötig horizontal zu skalieren.

Sowohl PHP als auch Apache weisen jeder offenen Anfrage Ressourcen zu. Wenn eines oder beide Systeme mehrere Bibliotheken laden müssen, können die Startzeit pro Anfrage und der Speicherbedarf erheblich sein. Durch den Umstieg auf NGINX als Webserver-Software wird dieses Problem auf Serverebene beseitigt. Wenn Sie die Funktionen von NGINX nutzen, um Aufgaben auf den Webserver (z. B. die Bereitstellung statischer Dateien) oder einen Reverse-Proxy-Server (verschiedene Arten von Caching, Protokollterminierung, Lastverteilung usw.) auszulagern, wird der Arbeitsaufwand für PHP minimiert und die Anwendungsverarbeitung vereinfacht und beschleunigt.

Wenn Sie für Ihre Website benutzerdefinierte oder proprietäre Apache-Module verwenden, können Sie Apache möglicherweise erst dann durch NGINX ersetzen, wenn Sie auch diese Module ersetzt haben. Erkundigen Sie sich bei NGINX, ob es einfache Umgehungslösungen gibt. Falls nicht, schätzen Sie den für die Umstellung erforderlichen Zeit- und Arbeitsaufwand ab.

Wenn Sie sich für NGINX entschieden haben, können Sie zwischen NGINX Open Source und NGINX Plus wählen. Zu den wichtigsten Vorteilen von NGINX Plus gegenüber NGINX Open Source gehören:

Vorkompilierter Code. NGINX Plus wird in kompilierter Form bereitgestellt und umfasst gängige Bibliotheken sowie dynamische Module, die Sie im laufenden Betrieb hinzufügen und entfernen können. (NGINX Open Source ist sowohl als kompilierter als auch als unkompilierter Code verfügbar.) Sie können zahlreiche Konfigurationsänderungen vornehmen, ohne den Server neu zu starten.
Support. NGINX Plus umfasst ein Supportpaket, das Ihnen direkten Zugang zu NGINX-Ingenieuren bietet.
Überwachung und Verwaltung. DevOps-freundliche Tools helfen Ihnen, den Betrieb Ihres Servers aufrechtzuerhalten und Service-Level-Agreements (SLAs) einzuhalten.

Als Reverse-Proxy-Server bietet NGINX Plus weitere Vorteile:

Lastverteilung. Beide Versionen von NGINX unterstützen eine grundlegende HTTP-Lastverteilung, NGINX Plus bietet jedoch zusätzlich ausgereiftere Algorithmen und TCP-Lastverteilung.
Sitzungspersistenz. Neben dem Lastenausgleich bietet NGINX Plus eine ausgefeiltere Sitzungspersistenz, die für PHP-Anwendungsserver häufig von großer Bedeutung ist.
Überwachung und Verwaltung. Der volle Funktionsumfang von Überwachung und Verwaltung mit NGINX Plus kommt bei einer Bereitstellung mit mehreren Servern zum Tragen; auch der Nutzen von vorkompiliertem Code und Support ist bei komplexeren Implementierungen am größten.

Sowohl NGINX Open Source als auch NGINX Plus unterstützen Content-Caching und Microcaching (auch als „Anwendungs-Caching“ bezeichnet). Caching ist im Kontext eines Webservers hilfreich, da es den Anwendungsserver entlastet. Beide Funktionen nutzen jedoch weiterhin dieselbe physische oder virtuelle Maschine. Auf einem Reverse-Proxy-Server kann Caching den Anwendungsserver erheblich entlasten und so größere Leistungsvorteile bieten.

Sie können die Software NGINX Open Source direkt von nginx.org herunterladen. Dort finden Sie auch Support durch die Community. Um ein einzelnes NGINX Plus-Abonnement abzuschließen, registrieren Sie sich für eine kostenlose 30-Tage-Testversion oder kaufen Sie es online. Für Pakete mit mehreren Instanzen wenden Sie sich an den NGINX-Vertrieb.

Tipp 3 – Apache-Konfiguration in NGINX-Syntax konvertieren

Wenn Sie von Apache zu NGINX als Webserver-Software wechseln, müssen Sie einige Änderungen vornehmen, die in einem hervorragenden Artikel auf sitepoint.com ausführlich beschrieben werden:

Konfigurationsdateien erstellen oder konvertieren. Ändern Sie den Konfigurationscode, um festzulegen, welche Dateien NGINX (anstelle von Apache) für die Konfiguration verwenden soll.
Lese-/Schreibberechtigungen ändern. Fügen Sie Ihrem Konto die Berechtigung hinzu, CRUD-Vorgänge (Erstellen, Lesen, Aktualisieren, Löschen) für Dateien im Stammverzeichnis der Website auszuführen.
Gültige Suchmuster festlegen. Fügen Sie einen location-Block hinzu, um festzulegen, welche Muster NGINX bei der Verarbeitung von Anfragen verwenden darf und welche nicht.
Ersetzen Sie den .htaccess-Konfigurationscode. Konfigurationsdetails für Apache befinden sich in der Regel in .htaccess-Dateien oder in statischen Konfigurationsdateien (mod_rewrite-Direktiven beispielsweise). Ersetzen Sie diese durch entsprechende Konfigurationsangaben in den NGINX-Konfigurationsdateien. Einige Beispiele finden Sie in unserem Blog.

Durch diese Änderungen machen Sie sich mit NGINX vertraut und schaffen die Voraussetzungen für die Optimierung komplexerer Websites, wie wir sie in Teil 2 dieses Blogbeitrags beschreiben. Falls diese Konfigurationsänderungen jedoch einen unvertretbar hohen Aufwand oder ein zu großes Risiko für den Betrieb Ihrer Website darstellen, besteht kein Grund zur Sorge: Sie können die in Teil 2 beschriebenen Architekturen mit mehreren Servern implementieren, ohne die zentrale Webserver-Software von Apache zu aktualisieren und somit ohne die Konfigurationsdateien Ihres Webservers zu ändern.

Tipp 4 – Caching statischer Dateien implementieren

Statische Dateien sind Dateien, die sich – zumindest aus Sicht eines Webservers – nur selten ändern. Dazu gehören in der Regel Grafikdateien wie JPEG- und PNG-Dateien sowie Codedateien wie CSS- und JavaScript-Dateien. Wenn Sie diese Dateien auf Ihrem Anwendungsserver oder auf einem separaten Datenbankserver ablegen, müssen entsprechende Anfragen vom Anwendungscode verarbeitet werden – einschließlich des gesamten Aufwands, der für das Erstellen und Bearbeiten einer Anfrage erforderlich ist. Dies „lenkt“ den Anwendungsserver von wichtigeren Aufgaben ab und kann dazu führen, dass der physische Arbeitsspeicher überlastet wird und bei neuen Anfragen Daten laufender Anfragen auf die Festplatte ausgelagert werden.

Das Caching statischer Dateien ist eine Kernfunktion von NGINX. Sie können es auf einem Webserver oder einem Reverse-Proxy-Server implementieren:

Auf einem NGINX-Webserver entlastet das Caching statischer Dateien den Anwendungsserver. Dateien werden schneller und mit deutlich geringerem Arbeitsspeicherbedarf abgerufen. Der Dateiabruf erfolgt jedoch weiterhin über denselben physischen Server bzw. dieselbe virtuelle Serverinstanz, sodass der Prozessor des Servers nach wie vor neben der Ausführung Ihrer Anwendung weitere Aufgaben bewältigen muss.
Ein NGINX-Reverse-Proxy-Server wird auf einem anderen Rechner bzw. einer anderen Instanz als der Webserver ausgeführt. Daher beansprucht das Caching statischer Dateien keine Ressourcen auf den Anwendungsservern. Der Anwendungsserver kann sich ausschließlich auf die Ausführung Ihrer Anwendung konzentrieren.

Die Implementierung der Zwischenspeicherung statischer Dateien mit NGINX umfasst insgesamt drei Schritte:

Festlegen des Stammverzeichnisses für Suchvorgänge.
Anfragen verarbeiten.
Optimierung der Antwortgeschwindigkeit.

Bei einem NGINX-Webserver ohne vorgeschalteten Reverse-Proxy-Server findet kein Caching im üblichen Sinne statt. Stattdessen leiten Sie Anfragen nach statischen Dateien mithilfe des X-Accel-Redirect-Headers einfach an den Webserver weiter. Der Anwendungsserver bekommt die Anfrage nie zu Gesicht und kann all seine Ressourcen für Anwendungsanfragen einsetzen. Bei einem Reverse-Proxy-Server hingegen werden statische Dateien zwischengespeichert. Der physische Server bzw. die virtuelle Serverinstanz, auf dem bzw. der die Anwendung ausgeführt wird, ist an der Beantwortung von Anfragen nach statischen Dateien nicht beteiligt.

Als Beispiel für die Optimierung der Antwortgeschwindigkeit ermöglicht das folgende Konfigurationsfragment NGINX die Verwendung des Systemaufrufs sendfile des Betriebssystems. Dadurch entfällt ein Schritt bei der Dateiübertragung, da die Datei nicht in einen Zwischenpuffer kopiert wird:

location /mp3 {    sendfile           on;
    sendfile_max_chunk 1m;
    # ...
}

Ausführliche Informationen zur Konfiguration von NGINX für das Caching statischer Dateien finden Sie im NGINX Plus-Administratorhandbuch.

Tipp 5 – Microcaching implementieren

Verwirrenderweise ist Microcaching unter vielen Bezeichnungen bekannt, darunter auch „Anwendungs-Caching“ oder schlicht „Caching“. Bei NGINX verwenden wir den Begriff „Microcaching“, um die kurze Gültigkeitsdauer solcher Dateien hervorzuheben.

Nehmen wir an, Sie haben eine Seite mit einem Blogbeitrag, auf der Benutzer Kommentare hinterlassen können. Sie möchten stets die neuesten Kommentare anzeigen, wenn ein neuer Besucher die Seite aufruft – oder wenn bestehende Benutzer die Seite aktualisieren, um ihren eigenen neuen Kommentar oder den eines anderen zu sehen. In diesem Fall scheint es sinnvoll, die Seite bei jedem Aufruf neu zu generieren.

Allerdings kann „jedes Mal“ schnell zur Belastung werden. Wenn eine Seite einmal pro Sekunde aufgerufen wird, ist es sinnvoll, sie bei jedem Aufruf neu zu generieren. Wird die Seite jedoch zehn-, hundert- oder tausendmal pro Sekunde aufgerufen – zusätzlich zu all den anderen Seiten der Website –, kann der Anwendungsserver überlastet werden. Das Ziel, den Nutzern stets aktuelle Inhalte bereitzustellen, führt dann dazu, dass niemand Inhalte schnell erhält.

Beim Microcaching wird eine Seite einmal generiert und die zwischengespeicherte Version für einen kurzen Zeitraum – beispielsweise eine oder wenige Sekunden – als gültig markiert. Sobald die zwischengespeicherte Version abläuft, wird beim nächsten Aufruf eine neue Seite generiert, und unmittelbar darauffolgende Aufrufe erhalten deren zwischengespeicherte Version. Dies entspricht dem Verhalten bei einer statischen Datei, allerdings in wesentlich kürzeren Zeitabständen.

Diese Abbildung zeigt, wo Sie auf Ihrer Website nach Inhalten suchen sollten, die sich per Microcaching zwischenspeichern lassen. Sie stammt aus einem Blogbeitrag über Microcaching unseres Kollegen Owen Garrett.

Viele dynamische Inhalte eignen sich für Microcaching.

Microcaching ist großartig, weil es den Anwendungsserver genau dann entlastet, wenn dies am dringendsten benötigt wird – und das mit nur sehr geringen oder gar keinen Nachteilen für die Benutzer. Es ist so großartig, dass es in einigen Systemen bereits integriert ist. Drupal hält seine robusten, integrierten Microcaching-Funktionen für so unverzichtbar, dass Microcaching in der Drupal-Welt schlicht als „Caching“ bezeichnet wird.

Die Drupal-Lösung weist jedoch einige Schwächen auf, ebenso wie jede vergleichbare Lösung. Der Anwendungsserver hat zwar weniger Arbeit, doch weiterhin muss Drupal (oder allgemeiner gesagt PHP) die Konfiguration, Implementierung und Bereitstellung der Dateien übernehmen. Durch den Einsatz von NGINX für das Microcaching wird der Anwendungsserver vollständig entlastet und muss lediglich in den vom Microcache festgelegten Abständen eine neue Seite erzeugen. Die übrigen Anfragen erreichen ihn nicht einmal, geschweige denn, dass er bei Cache-Treffern Daten speichern oder abrufen müsste.

Mit NGINX Plus oder anderen Tools können Sie Ihre Website überwachen und feststellen, welche Seiten von Microcaching profitieren. Der folgende Konfigurationsausschnitt legt für Antworten mit dem Statuscode 200 OK eine Cache-Dauer von 1 Sekunde fest.

proxy_cache_path /tmp/cache keys_zone=cache:10m levels=1:2 inactive=600s max_size=100m;server {
    proxy_cache cache;
    proxy_cache_valid 200 1s;
    # ...
}

Fazit zu Teil 1

Dieser erste Teil unseres PHP-Blogbeitrags konzentriert sich auf Einzelserverlösungen und Caching, das bei Einzelserverimplementierungen effektiv ist – aber noch mehr, wenn zusätzlich ein Reverse-Proxy-Server zum Einsatz kommt. Teil 2 beschreibt die Vorteile eines Reverse-Proxy-Servers und einer Multiserver-Implementierung für Ihre PHP-Anwendung.

Wenn Sie NGINX Plus ausprobieren möchten, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.