Maximieren der PHP 7-Leistung mit NGINX, Teil 1: Web-Serving und Caching

Einführung – So wird NGINX mit PHP verwendet

PHP ist mit einem Marktanteil von etwa 80 % die beliebteste Methode zum Erstellen serverseitiger Webanwendungen. (ASP.net liegt mit deutlichem Abstand auf dem zweiten Platz und Java auf einem noch weiter entfernten dritten Platz.)

Das PHP-Universum umfasst eine Vielzahl von PHP-Frameworks; zu den beliebtesten zählen Laravel, Phalcon und Symfony 2. PHP ist auch die Grundlage für beliebte Content-Management-Systeme (CMS) wie WordPress und Drupal . (Die neueste Drupal-Version, Drupal 8, enthält eine umfassende Symfony 2- Integration.

Jetzt 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 Internetnutzung als auch die Anforderungen an Websites exponentiell gestiegen. PHP hat zu diesem schnellen Wachstum beigetragen – doch gerade das Wachstum, das PHP ermöglicht hat, zeigt auch seine Grenzen auf.

PHP wird allgemein als leistungsstark und flexibel angesehen, unterliegt jedoch Leistungsproblemen. PHP-basierte Websites können bereits nach ein paar Verdoppelungen der Verkehrszahlen leicht gegen die Wand laufen. Gerade wenn eine Site beginnt, ihre geschäftlichen oder betrieblichen Ziele zu erreichen, stürzt sie ab, wenn das Datenverkehrsaufkommen steigt.

Bei Tausenden und Abertausenden von PHP-basierten Anwendungen haben einige relativ einfache Änderungen ausgereicht, um die Leistung zu verbessern. Hierzu gehören das Caching mit Tools wie Memcached , das Tuning von Datenbanken sowie Reverse-Proxy und Lastenausgleich mit NGINX Open Source und NGINX Plus . NGINX hat die Reaktionsfähigkeit der App erheblich verbessert und ermöglicht damit um ein Vielfaches höhere Benutzer- und Datenverkehrszahlen.

Dieser Blogbeitrag ist der erste einer zweiteiligen Reihe zum Thema „Maximieren Sie die Leistung Ihrer Websites, die PHP 7 verwenden“. Hier konzentrieren wir uns auf das Upgrade auf PHP 7, die Implementierung von NGINX Open Source oder NGINX Plus als Ihre Webserver-Software, das Neuschreiben von URLs (erforderlich, damit Anfragen richtig verarbeitet werden) und das Zwischenspeichern statischer Dateien und das Zwischenspeichern dynamischer Dateien (auch Anwendungs-Caching oder Microcaching genannt).

Im nächsten Blogbeitrag konzentrieren wir uns auf die Schritte, die Sie mit zusätzlichen Servern unternehmen können: Hinzufügen eines Reverse-Proxy-Servers, Umstellung auf mehrere Anwendungsserver, Lastausgleich zwischen mehreren Servern, Unterstützung der Sitzungspersistenz während des Lastausgleichs und Beenden von Sicherheitsprotokollen wie SSL/TLS und dem zugehörigen HTTP/2-Protokoll.

Warum PHP an seine Grenzen stößt

Warum geraten PHP-Anwendungen ins Stocken? Aus demselben Grund stößt jede Anwendungsserversoftware an ihre Grenzen. Wenn eine Benutzeranforderung eingeht, muss PHP – und die Webserver-Software, auf der es läuft – mehrere Dinge tun:

• Entschlüsseln Sie die Anfrage . Zuerst müssen die Webserver-Software und dann PHP Prozesse starten, um die Anfrage zu empfangen, zu entschlüsseln und zu verarbeiten. Der Apache HTTP Server beispielsweise weist Ressourcen zu, um jede Datenanforderung zu verarbeiten, egal wie einfach (Abrufen einer JPEG-Datei) oder komplex (Verarbeitung verschachtelter CSS-Anforderungen) sie ist. Dies alles nimmt Zeit in Anspruch, erfordert Systemressourcen und erfordert eine Speicherzuweisung, die ziemlich umfangreich sein kann, wenn das Betriebssystem, PHP oder beide eine Reihe von Bibliotheken laden müssen, bevor sie überhaupt mit der Verarbeitung der Anforderung beginnen können.
• Behandeln Sie unterstützende Protokolle . Wenn Sie SSL/TLS und/oder HTTP/2 ausführen, muss Ihre Webserversoftware Anfragen dekodieren, ein möglicherweise zeitaufwändiger Prozess.
• Handeln Sie entsprechend der Anfrage . PHP muss die Ressourcen zusammenstellen, um die Anfrage zu verarbeiten. Dies kann mehrere Datenbankaufrufe, Aufrufe externer Dienste über das Internet und eine komplizierte interne Verarbeitung erfordern.
• Antworten Sie auf die Anfrage . PHP muss die Ergebnisse an die Webserver-Software zurückgeben, damit sie als HTTP-Antwort an den Anforderer zurückgesendet werden können. Denken Sie daran, dass sowohl die Webserver-Software als auch PHP für jede Anfrage einen aktiven, dedizierten Thread ausführen, vom ersten Empfang bis zur endgültigen Bestätigung.

Das ist eine Menge, die ein physischer Server, eine virtuelle Maschine oder eine Cloud-Server-Instanz pro Anfrage verarbeiten muss. Wenn der physische Speicher auf dem Servercomputer – ob physisch oder virtuell – erschöpft ist, kommt es tendenziell zu Leistungseinbußen. Der Server beginnt dann mit dem Auslagern aktueller Sitzungen auf die Festplatte, wenn neue Anforderungen eingehen. Das Warten auf die Erfüllung von Dateianforderungen führt auch zu Wartezuständen, die ebenfalls zum Paging beitragen. Ab einem (sehr begrenzten) Punkt überfordern Paging-Operationen und Datenanforderungen die Verarbeitungsvorgänge, und die Leistung gerät in eine Todesspirale, die für frustrierte Benutzer zu langen Wartezeiten oder einer völligen Beendigung der Sitzung führt.

Beheben von Leistungsproblemen

Das Überwinden der Leistungsbarrieren von PHP ist durchaus möglich und erfordert mehrere sich ergänzende Schritte. Jeder Schritt kann mit anderen kombiniert werden. Im Wesentlichen handelt es sich dabei um:

• Das Problem wird mit Hardware gelöst . Mehr Speicher, mehr Speicher, schnellere Festplatten, separate Datenbankserver, ein Content Delivery Network, erhöhte Durchsatzkapazität und andere mechanische Lösungen sind eine schnelle und einfache Lösung für Leistungsprobleme. Diese Lösungen können die Betriebszeit aufrechterhalten oder die Leistung linear skalieren.
• Verbessern von PHP- und Anwendungscode . Neue PHP-Versionen, neue Frameworks und verbesserter Anwendungscode können sehr hilfreich sein. Auch hier ist eine Verdoppelung oder sogar Vervierfachung der Leistung möglich, ohne dass zusätzliche Ausgaben für neue Hardware anfallen.
• Verbesserte Serversoftware . Die meisten Webserver und PHP weisen jeder offenen Anfrage in Bearbeitung dedizierte Ressourcen zu. Die NGINX-Serversoftware verarbeitet Anfragen, sobald diese eingehen, ohne Ressourcen zu binden, und minimiert so den Server-Footprint.
• Multiserver-Implementierung . Sie können einen Reverse-Proxy-Server implementieren, um Internetanforderungen zu verarbeiten und diese (Lastausgleich) auf einen oder mehrere Anwendungsserver aufzuteilen. Der Reverse-Proxy-Server kann auch das Datei-Caching, die Beendigung von Protokollen wie SSL/TLS und HTTP/2 sowie die Verwaltung mehrerer Anwendungsserver übernehmen. Selbst bei nur einem Anwendungsserver wird dadurch ein großer Teil seiner Arbeitslast entlastet. Durch Lastenausgleich wird sichergestellt, dass beim Hinzufügen weiterer Server kein Server überlastet wird, obwohl ihm mehr Last zusteht als ihm zusteht.

Sie müssen diese Schritte nicht in einer bestimmten Reihenfolge ausführen. Selbst wenn Sie beispielsweise Apache als Ihren Webserver behalten und Ihren App-Server nicht auf PHP 7 aktualisieren, verbessert die bloße Implementierung von NGINX als Reverse-Proxy „vor“ Ihren vorhandenen Servern die Leistung und ermöglicht Ihnen die parallele Implementierung mehrerer Anwendungsserver.

Wie auch immer Sie vorgehen, die entscheidende Tatsache, die Sie im Hinterkopf behalten sollten, ist, dass Sie mit wenig oder gar keiner Änderung Ihres aktuellen Anwendungscodes die Leistung um ein Vielfaches steigern können, ja sogar die Kapazität um eine Größenordnung erhöhen können. Lesen Sie weiter, um zu erfahren, wie Menschen diese außergewöhnlichen Leistungssteigerungen bereits erreicht haben oder dabei sind, sie zu erreichen.

Notiz : Es gibt eine Multiserver-Optimierung, die wir in diesen Blog-Posts etwas ignorieren werden. Ein separater Datenbankserver und ein Content Delivery Network (CDN) können Ihren Anwendungsserver entlasten und die Leistung erheblich verbessern. Änderungen dieser Art erfolgen getrennt von den hier beschriebenen Anwendungs- und Implementierungsverbesserungen und laufen parallel dazu.

Tipp 1 – Upgrade auf PHP 7

Der Hauptgrund dafür, lieber früher als später auf PHP 7 zu aktualisieren, ist einfach: die Anwendungsgeschwindigkeit (die maßgeblich durch Speichereinsparungen ermöglicht wird). PHP 7 soll doppelt so schnell sein wie frühere PHP-Versionen und deutlich weniger Speicher verbrauchen. (Ihre Laufleistung wird in beiden Hinsichten zweifellos unterschiedlich sein.)

Die Reaktionszeit ist für Webanwendungen schlicht und ergreifend von entscheidender Bedeutung. Eine schnellere Web-App, die außerdem weniger Speicher verbraucht und so die Wahrscheinlichkeit eines Seitenwechsels und daraus resultierender Leistungsprobleme verringert, erreicht drei Dinge:

1. Sorgt für mehr Zufriedenheit bei den Benutzern und erhöht die Wahrscheinlichkeit, dass sie Ihre Site besuchen und dort Aufgaben erledigen, z. B. Artikel lesen, Produktinformationen abrufen, einen Kleinbus rufen, ein freies Zimmer mieten oder Dinge kaufen. Das sind die Gründe, aus denen Sie die Site oder App überhaupt erstellt haben.
2. Ermöglicht einem bestimmten Server, mehr Benutzer zu unterstützen, ohne dass die Gefahr besteht, dass er durch zusätzliche Benutzer langsamer wird oder sogar abstürzt. Es ist immer gut, das Unglück hinauszuzögern.
3. Macht Ihren Server weniger anfällig für Hackerangriffe, die Ihren Server überlasten und so die Produktion stoppen. Heutzutage wird jeder angegriffen, aber die Schwachen werden häufiger und aggressiver angegriffen. Weniger Verwundbarkeit kann also exponentiell besser sein als mehr.

Dies alles sind hervorragende Gründe für ein Upgrade. Zusammengenommen scheinen die Argumente für ein Upgrade nahezu überwältigend. Und zur Behebung vieler Probleme ist „Upgrade auf die neueste Version“ immer die erste Empfehlung, selbst wenn kein so offensichtlicher Leistungsvorteil vorliegt. Warum führt also nicht jeder sofort ein Upgrade durch?

Ganz einfach: Die Leute hassen es, alten Code herumzuspielen, und das aus gutem Grund. Wenn eine alte App ausreichend gut funktioniert und Entwickler durch die Erstellung neuer Apps bessere Ergebnisse erzielen als durch die Aktualisierung alter Apps, kann die alte App sehr lange unverändert bleiben. (Informationen dazu, wie Sie mit NGINX die Leistung Ihrer App verbessern können, ohne Änderungen an Ihrem aktuellen Webserver und Ihrer App vorzunehmen, finden Sie im zweiten Blogbeitrag dieser Reihe.)

Aber wenn überhaupt möglich, ist es effizienter, Ihr Streben nach mehr Leistung mit einem Upgrade auf PHP 7 zu beginnen. Beginnen Sie jedoch erst, wenn Sie genügend Zeit haben, um fertig zu werden, insbesondere ohne beim Testen zu vernachlässigen.

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

• Änderungen bei der Ausdrucksauswertung . Möglicherweise müssen Sie die Schreibweise einiger Ausdrücke ändern, damit diese in PHP 7 richtig ausgewertet werden. (Oder, wenn Sie wirklich vorsichtig sind und nicht alle Ihre PHP-Server auf einmal aktualisieren, stellen Sie sicher, dass sie sowohl in PHP 5.6 als auch in PHP 7 richtig ausgewertet werden.) Wenn Sie variable Variablen oder variable Eigenschaften haben, müssen Sie den Code überarbeiten, damit sie in beiden PHP-Versionen auf die gleiche Weise ausgewertet werden.
• Syntaxänderungen . PHP 7 unterstützt keine ASP- oder Skript-Tags. Für einen Schalter sind nicht mehrere Standardfälle möglich. (Wir lassen die Kontroverse über switch versus if-then-else beiseite.)
• Entfernung veralteter Funktionen . Alle möglichen Dinge , die in verschiedenen 5.x-Versionen von PHP veraltet waren, sind jetzt toter als ein toter Papagei . Sie funktionieren in PHP 7 einfach nicht. Wenn sie in Ihrem Code enthalten sind und Sie beim Versuch, sie alle zu entfernen, keinen Erfolg haben, wird die Funktionalität Ihres Einkaufswagencodes mit Sicherheit am Abend vor dem Cyber Monday um 23:59 Uhr verschwinden.
• Neue Funktionen . PHP 7 fügt eine Reihe neuer Funktionen hinzu, um jeden zum Upgraden alten Codes zu verleiten. Seien Sie jedoch vorsichtig, wenn Sie bei einer Code-Bereinigung neue Funktionen hinzufügen. Neue Funktionen sind oft wunderbar, sonst wären sie nicht hinzugefügt worden, aber sie ziehen auch Fehler an (Ihre und die anderer) und führen zu künftigen Überarbeitungen im Zuge weiterer PHP-Upgrades.
• Allgemeine Codeüberprüfung . Jedes Mal, wenn Sie Code berühren – oder besser gesagt, jedes Mal, wenn Sie eine Codedatei öffnen und nicht sicher sind, ob Sie Änderungen vorgenommen haben oder nicht – müssen Sie wirklich alles darin überprüfen, insbesondere alles, was Sie geändert haben.
• Testen . Alles muss ständig getestet werden. Wenn Sie Änderungen vornehmen, müssen Sie alles erneut testen. Das bedeutet jedoch noch lange nicht, dass Sie alle Fehler finden. Eine gut implementierte DevOps-Umgebung kann diese Tests relativ einfach machen, aber nur wenige von uns leben heute in diesem gelobten Land.

Dieses Blog bei 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 vollständige Leistungsüberprüfung und Überarbeitung Ihres Codes oder zumindest seiner kritischen Funktionen in Betracht ziehen, um die neuen Funktionen in PHP 7 zu nutzen. Es gibt für Sie und Ihr Team keinen besseren Weg, Ihre Fähigkeiten zu verbessern. Die Änderungen, die Sie heute vornehmen, überprüfen und testen, werden Ihnen wahrscheinlich noch viele Jahre lang von Nutzen sein. Sie werden auch die anderen Leistungsvorschläge in diesem Blogbeitrag optimal nutzen können, da optimierter Code stark davon profitiert, in einer optimierten Umgebung ausgeführt zu werden.

Auch wenn Websites häufig NGINX einsetzen, um eine bessere Leistung zu erzielen, ohne den Anwendungscode zu verändern, empfehlen wir Ihnen, die Zügel in die Hand zu nehmen und voranzuschreiten. Es gibt jede Menge Hilfe für den Umzug, aber Sie können auch einfach die Ärmel hochkrempeln und es selbst in die Hand nehmen . Auf der offiziellen PHP-Site gibt es einen Migrationsleitfaden für PHP 7 und von O'Reilly ein Anleitungsbuch zum PHP 7-Upgrade .

Tipp 2 – Wählen Sie 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 meistgenutzten Websites . (Diese Messungen erkennen den Webserver an Einzelserverstandorten und den Reverseproxyserver an Mehrserverstandorten.) Als Webserver bieten beide eine sofortige Leistungssteigerung – in manchen Fällen, in denen ein Server, auf dem andere Software läuft, überlastet war und bis zu zehnmal überlastet war. Als Reverse-Proxy-Server ermöglichen beide die Verwendung mehrerer dedizierter Server, um eine Bereitstellung beliebig weit zu skalieren.

Sowohl PHP als auch Apache weisen jeder offenen Anfrage Ressourcen zu. Wenn eines oder beide eine Reihe von Bibliotheken laden müssen, können die Startzeit pro Anfrage und der Speicherbedarf beträchtlich sein. Durch die Umstellung auf NGINX als Webserver-Software wird dieses Problem auf Serverebene behoben. Durch die Nutzung der NGINX-Funktionalität zum Auslagern von Arbeit auf den Webserver (z. B. Bereitstellen statischer Dateien) oder auf einen Reverse-Proxy-Server (alle Arten von Caching, Protokollabschluss, Lastausgleich usw.) wird der Arbeitsaufwand von PHP minimiert und die Anwendungsverarbeitung vereinfacht und beschleunigt.

Wenn Sie über benutzerdefinierte oder proprietäre Apache-Module für Ihre Site verfügen, können Sie Apache möglicherweise nicht durch NGINX ersetzen, bis Sie die Module ersetzen. Prüfen Sie bei NGINX, ob es einfache Workarounds gibt. Wenn nicht, schätzen Sie den für die Änderung erforderlichen Zeit- und Arbeitsaufwand ab.

Wenn Sie sich für NGINX entscheiden, haben Sie die Wahl zwischen NGINX Open Source und NGINX Plus. Zu den herausragendsten Funktionen von NGINX Plus gegenüber NGINX Open Source gehören:

• Vorkompilierter Code . NGINX Plus wird in kompilierter Form verteilt, einschließlich beliebter Bibliotheken und dynamischer Module, die Sie im Handumdrehen 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 .
• Unterstützung . NGINX Plus umfasst ein Support-Paket , das Ihnen direkten Zugang zu NGINX-Ingenieuren gewährt.
• Überwachung und Verwaltung . DevOps-freundliche Tools helfen Ihnen, Ihren Server am Laufen zu halten, um Service Level Agreements (SLAs) einzuhalten.

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

• Lastverteilung . Beide Versionen von NGINX unterstützen grundlegendes HTTP-Lastausgleich, aber NGINX Plus fügt ausgefeiltere Algorithmen und TCP-Lastausgleich hinzu.
• Sitzungspersistenz . Neben dem Lastausgleich bietet NGINX Plus eine ausgefeiltere Sitzungspersistenz , die für PHP-Anwendungsserver oft von großer Bedeutung ist.
• Überwachung und Verwaltung . Bei einer Bereitstellung mit mehreren Servern kommt die gesamte Bandbreite der Überwachungs- und Verwaltungsfunktionen von NGINX Plus zum Tragen. Auch bei komplexeren Implementierungen wird der Wert des vorkompilierten Codes und der Unterstützung maximiert.

Sowohl NGINX Open Source als auch NGINX Plus unterstützen Inhalts-Caching und Mikrocaching (auch Anwendungs-Caching genannt). Die Zwischenspeicherung ist im Webserverkontext hilfreich, da sie den Anwendungsserver entlastet, beide Funktionen jedoch weiterhin eine einzelne Maschine oder Instanz einer virtuellen Maschine gemeinsam nutzen. Auf einem Reverse-Proxy-Server kann das Caching das Anwendungsservergerät um einen erheblichen Teil der Arbeit entlasten und so größere Leistungsvorteile bieten.

Sie können die Open-Source-Software NGINX direkt von nginx.org herunterladen, wo Sie auch Community-Support finden. Um ein einzelnes NGINX Plus-Abonnement zu starten, registrieren Sie sich für eine kostenlose 30-Tage-Testversion oder kaufen Sie es online . Wenden Sie sich für Multiinstance-Pakete an den NGINX-Vertrieb .

Tipp 3 – Apache-Konfiguration in NGINX-Syntax konvertieren

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

• Erstellen oder konvertieren Sie Konfigurationsdateien . Ändern Sie den Konfigurationscode, um anzugeben, welche Dateien NGINX (nicht mehr Apache) für die Konfiguration verwenden soll.
• Lese-/Schreibberechtigungen ändern . Fügen Sie Ihrem Konto die Berechtigung hinzu, CRUD-Operationen (Erstellen, Lesen, Aktualisieren, Löschen) für Dateien im Stammverzeichnis der Website auszuführen.
• Geben Sie gültige Suchmuster an . Fügen Sie einen Standortblock hinzu, um anzugeben, welche Muster NGINX bei der Verarbeitung von Anfragen ausprobieren kann und welche nicht.
• Ersetzen Sie den .htaccess-Konfigurationscode . Konfigurationsdetails für Apache befinden sich in der Regel in .htaccess-Dateien oder in statischen Konfigurationsdateien (z. B. mod_rewrite- Direktiven). Ersetzen Sie diese durch relevante Konfigurationsspezifikationen in NGINX-Konfigurationsdateien. Einige Beispiele finden Sie in unserem Blog .

Durch diese Änderungen machen Sie sich mit NGINX vertraut und sind bereit, komplexere Websites zu optimieren, wie wir in Teil 2 dieses Blogbeitrags beschreiben. Wenn diese Konfigurationsänderungen jedoch einen unannehmbaren Arbeitsaufwand oder ein unannehmbares Risiko für den Betrieb Ihrer Site bedeuten, seien Sie unbesorgt – Sie können die in Teil 2 beschriebenen Multiserver-Architekturen implementieren, ohne die zentrale Webserver-Software von Apache zu aktualisieren und somit ohne die Konfigurationsdateien Ihres Webservers zu ändern.

Tipp 4 – Implementieren Sie ein statisches Datei-Caching

Statische Dateien sind einfach Dateien, die sich (zumindest in der Terminologie eines Webservers) nicht oft ändern. Zu den statischen Dateien zählen in der Regel Grafikdateien wie JPEGs und PNGs sowie Codedateien wie CSS- und JavaScript-Dateien. Wenn Sie diese Dateien auf Ihrem Anwendungsserver oder einem separaten Datenbankserver ablegen, müssen die entsprechenden Anforderungen vom Anwendungscode verarbeitet werden, wobei der gesamte Mehraufwand für die Erstellung und Erfüllung einer Anforderung anfällt. Dadurch wird der Anwendungsserver von wichtigeren Aufgaben „abgelenkt“ und es kann passieren, dass der physische Speicher überlastet ist und neue Anforderungen dazu führen, dass aktuelle Anforderungen auf die Festplatte ausgelagert werden.

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

• Auf einem NGINX-Webserver wird der Anwendungsserver durch das statische Datei-Caching entlastet; Dateien werden schneller und mit deutlich weniger Speicheraufwand abgerufen. Der Dateiabruf erfolgt jedoch weiterhin über denselben physischen Server oder dieselbe virtuelle Serverinstanz, sodass der Prozessor des Servers weiterhin mit anderen Aufgaben als der Ausführung Ihrer Anwendung beschäftigt ist.
• Ein NGINX-Reverse-Proxy-Server wird auf einer anderen Maschine oder Instanz als der Webserver ausgeführt, sodass das Zwischenspeichern statischer Dateien keine Ressourcen auf Anwendungsservern verbraucht. Der Anwendungsserver kann sich ausschließlich auf die Ausführung Ihrer Anwendung konzentrieren.

Die Implementierung des statischen Datei-Cachings auf NGINX umfasst drei allgemeine Schritte:

• Festlegen des Stammverzeichnisses für Suchvorgänge.
• Anfragen werden bearbeitet.
• Optimierung der Reaktionsgeschwindigkeit.

Auf einem NGINX-Webserver ohne beteiligten Reverse-Proxy-Server erfolgt kein Cachen im üblichen Sinne. Anfragen für statische Dateien leiten Sie einfach mithilfe des Headers „X-Accel-Redirect“ an den Webserver um. Der Anwendungsserver sieht die Anforderung nie und kann seine gesamten Ressourcen den Anwendungsanforderungen widmen. Mit einem Reverse-Proxy-Server verwenden Sie die Zwischenspeicherung statischer Dateien – und der physische Server oder die virtuelle Serverinstanz, auf der die Anwendung ausgeführt wird, ist an der Beantwortung der statischen Dateianforderungen nicht beteiligt.

Als Beispiel für die Optimierung der Antwortgeschwindigkeit ermöglicht der folgende Konfigurationsausschnitt NGINX, den Sendfile -Systemaufruf des Betriebssystems zu verwenden, wodurch ein Schritt bei der Dateiübertragung eingespart wird, indem die Datei nicht in einen Zwischenpuffer kopiert wird:

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

Einzelheiten zur Konfiguration von NGINX für die Zwischenspeicherung statischer Dateien finden Sie im NGINX Plus-Administratorhandbuch .

Tipp 5: Implementieren Sie Microcaching

Microcaching hat verwirrenderweise viele Namen, darunter auch Anwendungs-Caching und einfaches Caching . Hier bei NGINX verwenden wir den Begriff „Mikrocaching“, um die kurze Gültigkeitsdauer solcher Dateien zu betonen.

Nehmen wir an, Sie haben eine Blog-Beitragsseite, die einen Mechanismus für Benutzerkommentare bereitstellt. Sie möchten die neuesten und besten Kommentare jedes Mal einbeziehen, wenn ein neuer Besucher auf die Seite kommt – oder jedes Mal, wenn bestehende Benutzer die Seite aktualisieren, um ihren eigenen oder den neuen Kommentar einer anderen Person anzuzeigen. In diesem Fall erscheint es sinnvoll, die Seite bei jedem Besuch neu zu generieren.

Allerdings kann „jedes Mal“ zur Belastung werden. Wenn eine Seite einmal pro Sekunde besucht wird, ist es sinnvoll, die Seite für jeden Besuch neu zu generieren. Wenn die Seite jedoch zusammen mit allen anderen Seiten der Site zehn, hundert oder tausend Besuche pro Sekunde erhält, kann der Anwendungsserver überlastet werden. Das Ziel, den Leuten aktuelle Inhalte bereitzustellen, besteht darin, dass niemand schnell an Inhalte kommt.

Microcaching bedeutet, dass eine Seite einmalig generiert wird und die zwischengespeicherte Version für einen kurzen Zeitraum – beispielsweise eine Sekunde oder wenige Sekunden – als gültig markiert wird. Wenn die zwischengespeicherte Version abläuft, wird bei der nächsten Anforderung die Generierung einer neuen Seite veranlasst und unmittelbar darauf werden Anforderungen zum Abrufen der zwischengespeicherten Version gestellt. Dies ist das gleiche Verhalten wie bei einer statischen Datei, allerdings in viel kürzeren Zeiträumen.

Dieses Bild zeigt, wo Sie auf Ihrer Site nach Inhalten suchen müssen, die Sie im Mikrocache zwischenspeichern können. Es stammt aus einem Microcaching-Blogbeitrag unseres eigenen Owen Garrett.

Microcaching ist großartig, weil es dem Anwendungsserver genau dann Arbeit entzieht, wenn sie am dringendsten benötigt wird und dies mit kaum oder gar keinen Nachteilen für den Benutzer. Es ist so großartig, dass es in einige Systeme integriert ist. Drupal erachtet seine robusten, integrierten Microcaching-Funktionen als so wichtig, dass Microcaching in der Drupal-Welt einfach „Caching“ genannt wird.

Allerdings weist die Drupal-Lösung einige Mängel auf, und das gilt auch für ähnliche Lösungen. Der Anwendungsserver übernimmt weniger Arbeit, aber es ist immer noch Drupal (oder allgemeiner PHP), das die Konfiguration, Implementierung und Dateibereitstellung verwalten muss. Durch die Verwendung von NGINX für das Mikrocaching wird der Anwendungsserver vollständig von allen Aufgaben entlastet, mit Ausnahme der Generierung einer neuen Seite in der vom Mikrocache angegebenen Häufigkeit. Es sieht nicht einmal die anderen Anfragen, geschweige denn, dass es für Cache-Treffer etwas speichern oder abrufen muss.

Mit NGINX Plus oder anderen Tools können Sie Ihre Site überwachen und sehen, welche Seiten vom Microcaching profitieren. Das folgende Konfigurations-Snippet implementiert eine 1‑Sekunden‑Caching‑Periode für Antworten mit einem 200OK -Statuscode.

Proxy-Cache-Pfad /tmp/cache Schlüsselzone=Cache:10m Ebenen=1:2 inaktiv=600s max_size=100m;Server {
Proxy-Cache Cache;
Proxy-Cache_gültig 200 1s;
# ...
}

Fazit zu Teil 1

In diesem ersten Teil unseres PHP-Blogbeitrags geht es um Einzelserverlösungen und Caching, das bei Einzelserverimplementierungen effektiv ist – aber noch effektiver, wenn ein Reverse-Proxy-Server mit im Spiel ist. Teil 2 beschreibt die Vorteile einer Reverse-Proxy-Server-Multiserver-Implementierung rund um Ihre PHP-Anwendung.

Um NGINX Plus auszuprobieren, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.