Ein Blick auf den modernen WordPress-Server-Stack

Erinnerst du dich, als du eine „schnelle“ WordPress-Website nur mit einem Apache-Server und PHP betreiben konntest? Ja, das waren noch Zeiten! Damals war vieles unkomplizierter.

Jetzt muss alles blitzschnell geladen werden! Besucher haben nicht mehr die gleichen Erwartungen an Ladezeiten wie früher. Eine langsame Website kann schwerwiegende Folgen für Sie oder Ihren Kunden haben.

Weiterführende Literatur zu SmashingMag:

• Korrekte Berechtigungen und Eigentumsrechte für das WordPress-Dateisystem
• Verschieben einer WordPress-Website ohne Probleme
• So entwickeln Sie WordPress lokal mit MAMP
• Do-It-Yourself-Caching-Methoden mit WordPress

Folglich musste sich der WordPress-Server-Stack im Laufe der Jahre weiterentwickeln , um mit diesem Geschwindigkeitsbedarf Schritt zu halten. Als Teil dieser Entwicklung mussten dem Motor einige Gänge hinzugefügt werden. Einige der älteren Getriebe mussten ebenfalls geändert werden.

Das Ergebnis ist, dass der WordPress-Server-Stack heute ganz anders aussieht als noch vor ein paar Jahren. Um ihn besser zu verstehen, werden wir diesen neuen Stack im Detail untersuchen. Sie werden sehen, wie die verschiedenen Teile zusammenpassen, um eine WordPress-Website schnell zu machen.

Überblick

Lassen Sie uns vor dem Eintauchen herauszoomen und das Gesamtbild betrachten. Wie sieht dieser neue WordPress-Server-Stack aus? Nun, hier ist die Antwort:

Das obige Diagramm gibt einen guten Überblick darüber, wie der moderne WordPress-Server-Stack aussieht. Auf hoher Ebene können wir das, was vor sich geht, in drei Bereiche unterteilen:

• der Anfrage-Antwort-Zyklus zwischen dem Browser und WordPress;
• WordPress (ein Skript, das die PHP-Laufzeit ausführt);
• der Abfrage-Ergebnis-Zyklus zwischen WordPress und der MySQL-Datenbank.

Die Rolle des modernen WordPress-Serverstacks besteht darin, diese drei Bereiche zu optimieren. Diese Optimierungen sorgen dafür, dass alles schneller geladen wird. Und das Beste daran ist, dass es mehrere Möglichkeiten gibt, dies zu tun. (Yay!)

In den meisten Fällen beinhalten diese Optimierungen die Installation neuer Dienste auf Ihrem Server. Manchmal benötigen diese Dienste die Hilfe eines Plugins, um mit WordPress zu interagieren. Es wird auch Zeiten geben, in denen Sie mit der Installation eines Plugins davonkommen können. In diesem Artikel werden Sie viele verschiedene Optionen sehen.

Der Request-Response-Zyklus

Alles beginnt mit dem Browser. Angenommen, Sie möchten die Startseite von modern.wordpress-stack.org . Ihr Browser beginnt mit dem Senden einer HTTP-Anforderung an den Webserver, der ihn hostet. Am anderen Ende nimmt der Webserver Ihre Anfrage entgegen und wandelt sie in eine HTTP-Antwort um.

Diese erste Antwort sollte immer der HTML-Inhalt der Startseite von modern.wordpress-stack.org (sofern kein Fehler vorliegt). Die Arbeit Ihres Browsers ist jedoch noch nicht erledigt. Nein, diese Homepage benötigt noch mehr Dateien, die häufigsten sind CSS-, JavaScript- und Bilddateien.

Der Browser sendet also Anfragen nach diesen Dateien. Der Webserver antwortet mit den angeforderten Dateien (wiederum solange keine Fehler vorliegen). Dieser Zyklus wird fortgesetzt, bis der Browser über genügend Informationen zum Rendern der Homepage verfügt. Je schneller dieser Zyklus abläuft, desto schneller scheint die Website geladen zu werden.

Nun, das ist eine offensichtliche Vereinfachung, aber so funktionieren die Dinge für die meisten WordPress-Websites.

Optimierung des Request-Response-Zyklus

Okay, das bringt uns zu der offensichtlichen Frage: Wie bringen wir einen Webserver dazu, diesen Zyklus schneller auszuführen? Dies ist eine großartige Frage und einer der Gründe, warum es den modernen WordPress-Server-Stack gibt.

Der Stack existiert, weil man einen Webserver nicht einfach schneller machen kann. Ein Webserver ist auch ein Dispatcher. Es kann eine Anfrage entgegennehmen und sie einfach an andere Dienste weiterleiten.

Diese anderen Dienste sind oft der Flaschenhals dieses Anfrage-Antwort-Zyklus. Bei WordPress ist dieser Engpass PHP, weshalb die Optimierung des Request-Response-Zyklus auf zwei Dinge hinausläuft. Wir möchten, dass der Webserver:

• so wenig Anfragen wie möglich erhalten,
• so wenige Anfragen wie möglich an PHP weiterleiten.

Der moderne WordPress-Server-Stack konzentriert sich auf letzteres. Es möchte so wenig Anfragen wie möglich an PHP weiterleiten. Das wird das Hauptziel für die Optimierung des Stacks sein.

Wir konzentrieren uns auf das zweite Ziel, weil der Stapel nicht viel gegen das erste tun kann; es hat keinen direkten Einfluss darauf. Der zweite wird entweder durch die Konfiguration des Webservers oder durch moderne Entwicklungstechniken adressiert.

Stack-Elemente für den Request-Response-Zyklus

Was sind also die Stack-Elemente, die uns helfen, die an PHP weitergeleiteten Anfragen zu reduzieren? Nun, vor allem zwei Stack-Elemente werden uns dabei helfen, dieses Ziel zu erreichen: der Webserver und der HTTP-Cache.

Webserver

Wir haben schon ziemlich viel über Webserver gesprochen. Es gibt drei große Player im Webserver-Bereich:

• Apache
• Internetinformationsdienste (IIS)
• nginx

Zusammen machen diese mehr als 90 % des Marktanteils von Webservern im Internet aus. Wir werden uns auf Apache und Nginx konzentrieren. Obwohl IIS zum Ausführen von WordPress verwendet werden kann, ist dies nicht üblich, da es nur für Windows verfügbar ist und die meisten WordPress-Server Linux verwenden.

Damit bleiben uns Apache und nginx. Während der gesamten Lebensdauer von WordPress war Apache der empfohlene Webserver. Wir hatten den LAMP-Stack (Linux, Apache, MySQL und PHP), der WordPress sowohl auf dem Computer als auch auf dem Server ausführte.

Aber hinter den Kulissen änderten sich die Dinge. Es gab einen neuen Spieler in der Stadt, und sein Name war nginx. Automattic und WordPress.com verwenden es seit 2008. Es ist der Webserver, der den größten Prozentsatz der stark frequentierten Websites betreibt (von denen viele WordPress ausführen). Aus diesem Grund verwenden viele High-End-Hosting-Unternehmen und Top-WordPress-Agenturen es als ihren Webserver.

Es ist nicht so, dass Apache ein schlechter Webserver ist. Es gibt Apache-Experten, die dafür sorgen können, dass es unter viel Verkehr großartig läuft. Es funktioniert einfach nicht so gut aus der Box oder mit der Standard-WordPress-Konfiguration.

In der Zwischenzeit besteht der einzige Zweck von nginx darin, viel Verkehr zu bewältigen. Deshalb hat Igor Sysoev das Projekt gestartet, als er noch bei Rambler arbeitete.

Einer der Gründe, warum nginx mehr Datenverkehr besser verarbeitet, ist, dass es FastCGI verwendet, um mit PHP zu kommunizieren. Was ist FastCGI? Es ist ein Protokoll, mit dem PHP als vom Webserver getrennter Dienst ausgeführt werden kann.

Apache tut dies standardmäßig nicht. Jedes Mal, wenn der Webserver eine Anfrage erhält, muss er einen PHP-Laufzeitprozess starten – sogar für Bilder, JavaScript und CSS. Dies reduziert die Anzahl der Anforderungen, die der Server verarbeiten kann, und die Geschwindigkeit, mit der er sie verarbeiten kann.

Dies widerspricht einem der Ziele des modernen WordPress-Server-Stacks, das wir zuvor gesehen haben. Der Stack muss die Anfrage-Antwort-Zykluszeit so gering wie möglich halten. Das Laden von PHP für jede Anfrage, selbst wenn es nicht benötigt wird, widerspricht diesem Ziel. Wenn Sie also Apache verwenden, schauen Sie sich FastCGI an.

HTTP/2 ist ein weiteres wichtiges Webserver-Feature, das Sie kennen sollten. Es ist die nächste Version von HTTP, dem Protokoll, das unseren gesamten Anfrage-Antwort-Zyklus antreibt.

Vor der Einführung von HTTP/2 konnte ein Browser nur sechs Verbindungen zum Webserver haben. Und jede Verbindung konnte jeweils nur eine Anfrage verarbeiten. In der Praxis wurde ein Anfrage-Antwort-Zyklus also auf sechs Anfragen pro Zyklus begrenzt.

Das ist ein echtes Problem. Die meisten Websites haben Dutzende von Anfragen in ihrem Zyklus. Entwickler und Systemadministratoren haben clevere Wege gefunden, diese Einschränkung zu umgehen.

Eine der bekannteren Problemumgehungen ist die Praxis, CSS- und JavaScript-Dateien zu kombinieren. Im Idealfall würde dies die Gesamtzahl der Anfragen für CSS- und JavaScript-Dateien auf zwei reduzieren: eine für JavaScript und eine für CSS.

Dies ist bei HTTP/2 nicht erforderlich. HTTP/2 erlaubt eine unbegrenzte Anzahl von Anfragen pro Verbindung. Dadurch können alle zusätzlichen Anforderungen nach der anfänglichen HTML-Antwort gleichzeitig erfolgen.

Dies hat enorme Auswirkungen auf die Leistung. Ein Großteil der Arbeit zur Optimierung des Server-Stacks konzentriert sich auf den Anfrage-Antwort-Zyklus. Durch die Reduzierung der Anzahl der Zyklen auf nur eine Handvoll hat HTTP/2 eine enorme Menge an Arbeit für uns erledigt.

HTTP-Cache

Der wichtigste Teil des modernen WordPress-Server-Stacks ist der HTTP-Cache. In der WordPress-Welt nennen wir das auch Seiten-Caching. Der Zweck des HTTP-Cache besteht darin, Antworten auf Anforderungen zwischenzuspeichern. Was bedeutet das?

Nun, gehen wir zurück zu unserem vorherigen Beispiel. Der Browser sendet eine Anfrage für die Startseite von modern.wordpress-stack.org , und der Webserver empfängt diese Anfrage und leitet sie an PHP weiter.

Das Problem bei diesem Szenario ist, dass der Webserver dumm ist. Es leitet immer alle Anfragen, die es erhält, an PHP weiter – unabhängig davon, ob die meisten Anfragen dieselbe Antwort generieren würden.

Genau das passiert, wenn Besucher nicht eingeloggt sind. Für den Webserver sind das alles verschiedene Anfragen, aber das ist ihm egal. Es leitet sie alle an PHP weiter, das für alle die gleiche Antwort generiert.

Das ist schrecklich! Wie wir bereits gesehen haben, ist PHP der eigentliche Flaschenhals unseres Request-Response-Zyklus. Ihr Browser kann keine Folgeanfragen senden, bis er diese erste Startseitenantwort erhält. Wir können den Webserver nicht standardmäßig alles an PHP weiterleiten lassen.

Hier kommt der HTTP-Cache ins Spiel. Er befindet sich zwischen dem Webserver und PHP. Seine Aufgabe ist es, jede Anfrage, die der Webserver erhält, zu überprüfen und nach einer zwischengespeicherten Antwort zu suchen. Wenn es keine gibt, leitet es die Anfrage an PHP weiter und speichert dann die von PHP generierte Antwort im Cache.

Dadurch wird die Anfrage-Antwort-Zykluszeit drastisch reduziert, wodurch die Website schneller geladen wird. Außerdem kann der Webserver mehr gleichzeitige Anforderungen verarbeiten, ohne zu explodieren.

Die verschiedenen Arten von HTTP-Cache

An diesem Punkt sollten Sie sich fragen: „Wie bekomme ich dieses Baby so schnell wie möglich auf meinen Server?!“ Die gute Nachricht ist, dass die Installation eines HTTP-Caches auf einem WordPress-Server recht einfach ist. Es ist die Komponente mit den meisten Optionen.

Installieren Sie ein Page-Caching-Plugin

Am einfachsten ist es, ein Page-Caching-Plugin zu installieren. Sie haben einige Optionen zur Auswahl:

• Batch-Cache
• Hyper-Cache
• Cache-Enabler
• WP-Rakete
• WP-Super-Cache
• W3 Gesamtcache

Alle außer WP Rocket sind als kostenlose Plugins im WordPress-Verzeichnis verfügbar. Sie können also sofort einen installieren und testen. Davon abgesehen ist das beste der vier Plugins WP Rocket. Obwohl es sich um ein kostenpflichtiges Plugin handelt, macht es viel mehr als nur einen HTTP-Cache zu erstellen. Diese anderen Vorteile vergrößern die Arbeit, die der HTTP-Cache leistet.

Wie funktioniert ein Page-Caching-Plugin?

Alle diese Plugins nutzen ein Drop-In, das WordPress für das Caching zur Verfügung gestellt hat. Mit diesem Caching-Drop-In können die Plugins ein HTTP-Cache-System innerhalb von WordPress erstellen. Das Caching-Drop-In benötigt zwei Dinge, um zu funktionieren.

Zunächst muss sich die Drop-in-Datei advanced-cache.php im wp-content Ordner befinden. Das ist die eigentliche Datei. Aber im Gegensatz zu den meisten WordPress-Drop-Ins tritt dieses nicht standardmäßig ein. WordPress benötigt auch die WP_CACHE Konstante, um true zu sein, um das Drop-in zu laden. In den meisten Fällen würdest du das in wp-config.php .

Das obige Diagramm zeigt, was passiert, wenn Sie das Drop-in mit einem Caching-Plugin aktivieren. WordPress lädt das Drop-In während des Ladevorgangs in die wp-settings.php . Dies ist früh genug im Prozess, dass WordPress noch nichts Zeitaufwendiges getan hat.

Das Caching-Plugin prüft dann, ob es die Antwort auf die Anfrage bereits zwischengespeichert hat. Wenn dies der Fall ist, wird diese zwischengespeicherte Antwort zurückgegeben. Wenn dies nicht der Fall ist, wird die PHP-Ausgabepufferung aktiviert und WordPress wird weiter geladen.

Nun ist die Ausgangspufferung ein interessantes System. Es erfasst die gesamte Ausgabe eines PHP-Skripts in einer String-Variablen, bis eines von zwei Dingen passiert:

• Sie teilen PHP mit einer der eingebauten Funktionen mit, die Ausgabe nicht mehr zu puffern,
• Das PHP-Skript wird beendet und muss eine Antwort an den Browser zurückgeben.

Das Caching-Plugin setzt auf letzteres Szenario. Es möchte, dass WordPress seine Sache erledigt und dann die gesamte Ausgabe zwischenspeichert, bevor PHP sie an den Browser zurücksendet. Sie können den Prozess im Diagramm unten sehen.

Lassen Sie es den Webserver tun

Die nächste Option besteht darin, einen HTTP-Cache auf Webserverebene hinzuzufügen. Es funktioniert so, dass der Webserver alle Antworten auf Anfragen zwischenspeichert, die an PHP weitergeleitet werden. Diese Lösung ist besser als ein Caching-Plugin, da sie PHP überhaupt nicht berühren muss.

Das obige Diagramm gibt einen Überblick darüber, was im Webserver vor sich geht. Der Webserver erhält eine Anfrage und prüft mit dem HTTP-Cache. Wenn eine Antwort bereits zwischengespeichert wurde, sendet der HTTP-Cache diese zurück.

Andernfalls leitet es die Anfrage an das PHP-Modul (normalerweise FastCGI) weiter. Es leitet die Anfrage an WordPress weiter, damit es eine Antwort generieren kann. Das HTTP-Cache-Modul wird diese Antwort dann auf dem Rückweg zwischenspeichern.

Sowohl Apache als auch nginx bieten die Möglichkeit, ein HTTP-Cache-System hinzuzufügen. Das nginx-Modul ist integriert. Das Apache-Modul ist ein separates Modul, das Sie Ihrer Apache-Installation hinzufügen müssen.

Es gibt nicht viele Informationen zur Verwendung des Apache-Moduls mit PHP oder WordPress. Das könnte daran liegen, dass es bei den Apachen nicht beliebt ist, oder weil es einige Probleme hat. Es gibt mindestens ein seit langem bestehendes Problem, das noch offen ist.

Inzwischen ist das HTTP-Cache-System von nginx robust und gut dokumentiert. Sie können es als normalen HTTP-Cache oder als kleineren, aber effektiven Micro-Cache verwenden. Dies ist nur ein weiterer Grund, warum nginx heutzutage der bevorzugte Webserver ist.

Fügen Sie dem Stapel Lack hinzu

Was ist Lack? Es ist ein dedizierter HTTP-Cache-Server (oder, wie seine Entwickler es gerne nennen, HTTP-Beschleuniger). Die meisten stark frequentierten Websites und Premium-Hosting-Unternehmen verwenden es als HTTP-Cache-Lösung.

Sie verwenden es, weil es leistungsfähig ist und die größte Flexibilität bietet. Varnish hat seine eigene Konfigurationssprache namens VCL. Damit können Sie jedes Element des Caching-Prozesses steuern. Varnish enthält auch viele Tools zum Analysieren, was der Cache tut und wie er funktioniert.

Dies sind die Hauptunterschiede zwischen der Verwendung und der Verwendung des integrierten HTTP-Cache des Webservers. Der eingebaute HTTP-Cache des Webservers ist sehr leistungsfähig, aber auch ziemlich einfach. Sie haben nicht viel Kontrolle über ein paar Konfigurationsoptionen.

Diese Leistung und Flexibilität haben jedoch ihren Preis. Varnish ist auch die komplizierteste HTTP-Cache-Option. Es tut nichts anderes, als HTTP-Antworten zwischenzuspeichern. Es behandelt keine SSL-Beendigung, was die meisten WordPress-Entwickler wollen (oder wollen sollten). Das bedeutet, dass unser moderner WordPress-Server-Stack komplexer wird, wenn wir ihn verwenden.

Das obige Diagramm veranschaulicht diese zusätzliche Komplexität. Wir haben jetzt zwei weitere Komponenten in unserem WordPress-Server-Stack: Varnish und einen Reverse-Proxy.

Der Reverse-Proxy ist dazu da, die Beschränkung zu überwinden, die Varnish mit SSL hat. Es sitzt vor Varnish und entschlüsselt die Anfragen, die unser Server erhält. Sie können diese Art von Reverse-Proxy auch als SSL-Terminierungsproxy bezeichnen. Der Proxy sendet dann diese entschlüsselten Anfragen zur Verarbeitung an Varnish.

Sobald eine Anfrage Varnish erreicht, treten die VCL-Konfigurationsdatei(en) in Kraft. Sie sind Varnishs Gehirn. Zum Beispiel sagen sie ihm, wie es:

• eingehende Anfragen analysieren, bereinigen und ändern;
• Suchen Sie nach einer zwischengespeicherten Antwort.
• Analysieren, bereinigen und ändern Sie die von WordPress zurückgegebenen Antworten;
• cachen Sie diese zurückgesendeten Antworten;
• Behandeln Sie eine Anfrage, um eine oder mehrere Antworten aus dem Cache zu entfernen.

Letzteres ist besonders wichtig. Sich selbst überlassen, hat Varnish keine Möglichkeit zu wissen, wann WordPress eine Seite aus dem Cache entfernen möchte. Wenn Sie also Änderungen an einem Beitrag vornehmen und ihn aktualisieren, sehen die Besucher standardmäßig dieselbe zwischengespeicherte Seite. Zu unserem Glück gibt es ein Plugin, das Seiten aus dem Varnish-Cache entfernt.

WordPress

Alles klar, unsere Anfrage nach der Homepage von modern.wordpress-stack.org hat WordPress erreicht. Es durchlief den Anfrage-Antwort-Zyklus, den wir gerade behandelt haben. Der HTTP-Cache hat alles getan, um eine HTTP-Antwort zum Zurücksenden zu finden.

Es gab jedoch keine zwischengespeicherte HTTP-Antwort, die an den Browser zurückgesendet werden konnte. Zu diesem Zeitpunkt hatte der HTTP-Cache keine andere Wahl. Es musste die HTTP-Anfrage an WordPress weiterleiten.

Es liegt jetzt alles in den Händen von WordPress. WordPress muss unsere HTTP-Anfrage in eine HTTP-Antwort umwandeln und an den HTTP-Cache zurücksenden. Wie wir bereits gesehen haben, ist dies der Hauptengpass unseres gesamten modernen WordPress-Server-Stacks.

Die Ursache für diesen Engpass ist zweifach. WordPress hat eine Menge PHP-Code auszuführen. Dies ist zeitaufwändig und je langsamer PHP dabei ist, desto länger dauert es.

Der andere Engpass sind die Datenbankabfragen, die WordPress durchführen muss. Datenbankabfragen sind teure Vorgänge. Je mehr es gibt, desto langsamer wird WordPress. Dies wird der Schwerpunkt des letzten Abschnitts über den Anfrage-Ergebnis-Zyklus sein.

Optimierung der PHP-Laufzeit

Kommen wir zurück zu PHP. Derzeit hat WordPress eine Mindestanforderung von PHP 5.2. Diese Version von PHP ist fast 10 Jahre alt! (Das PHP-Team hat die Unterstützung 2011 eingestellt.)

Das PHP-Team hat all die Jahre nicht untätig herumgesessen. Insbesondere in den letzten Jahren wurden zahlreiche Leistungsverbesserungen vorgenommen. Schauen wir uns an, was Sie heute tun können, um es zu optimieren.

Verwenden Sie die neueste Version von PHP

Das Einfachste, was Sie tun können, ist, Ihre PHP-Version zu aktualisieren. Die Versionen 5.4, 5.5 und 5.6 sahen alle Leistungsverbesserungen. Die größte Verbesserung war von 5,3 auf 5,4. Der Wechsel dazu erhöhte die Leistung von WordPress um einen anständigen Betrag.

Installieren Sie das Opcode-Caching

Opcode-Caching ist eine weitere Möglichkeit, PHP zu beschleunigen. Als serverseitige Skriptsprache hat PHP einen großen Fehler: Es muss bei jeder Ausführung ein PHP-Skript kompilieren.

Die Lösung für dieses Problem besteht darin, den kompilierten PHP-Code zwischenzuspeichern. Auf diese Weise muss PHP es nicht jedes Mal kompilieren, wenn es es ausführt. Dies ist die Aufgabe des Opcode-Cache.

Vor PHP 5.5 wurde PHP nicht mit einem Opcode-Cache geliefert. Sie mussten es selbst auf dem Server installieren. Dies ist ein weiterer Grund, warum die Verwendung einer neueren Version von PHP besser ist.

Wechseln Sie zu einem Compiler der nächsten Generation

Das Letzte, was Sie tun können, ist, zu einem der beiden Compiler der nächsten Generation zu wechseln: entweder Facebooks HHVM oder PHP 7, die neueste Version von PHP. (Warum PHP 7? Das ist eine lange Geschichte.)

Facebook und das PHP-Team haben diese beiden Compiler von Grund auf neu entwickelt. Sie wollten modernere Kompilierungsstrategien nutzen. HHVM verwendet die Just-in-Time-Kompilierung, während PHP 7 die Ahead-of-Time-Kompilierung verwendet. Beide bieten unglaubliche Leistungsverbesserungen gegenüber dem guten alten PHP 5.

HHVM war der erste, der vor ein paar Jahren auf die Bühne kam. Viele Top-Hosts haben damit großen Erfolg und bieten es als ihren primären PHP-Compiler an.

Es sollte jedoch betont werden, dass HHVM kein offizieller PHP-Compiler ist. Es ist nicht 100% kompatibel mit PHP. Der Grund dafür ist, dass HHVM nicht nur für die Unterstützung von PHP entwickelt wurde; Es ist auch ein Compiler für die Programmiersprache Hack von Facebook.

PHP 7 ist ein offizieller PHP-Compiler. Es gibt es schon lange nicht mehr. Das PHP-Team hat es im Dezember 2015 veröffentlicht. Dies hat einige WordPress-Hosting-Unternehmen nicht daran gehindert, es bereits zu unterstützen.

Die gute Nachricht ist, dass WordPress selbst zu 100 % mit beiden Compilern kompatibel ist! Die schlechte Nachricht ist, dass dies nicht alle Plugins und Themes sind, denn die Mindest-PHP-Version für WordPress ist immer noch 5.2.

Nichts zwingt Autoren, ihre Plugins oder Themes mit diesen Compilern zum Laufen zu bringen. Sie können also nicht mit einem von ihnen All-in gehen. Ihr Stack sollte immer auf PHP 5 zurückgreifen.

Abfrage-Ergebnis-Zyklus

An diesem Punkt durchläuft die PHP-Laufzeit alle WordPress-PHP-Dateien und führt sie aus. Diese WordPress-PHP-Dateien enthalten jedoch keine Daten. Sie enthalten nur den WordPress-Code.

Das Problem ist, dass WordPress alle seine Daten in einer MySQL-Datenbank speichert. Um dorthin zu gelangen, muss die PHP-Laufzeit diese Datenbank abfragen. Der MySQL-Server gibt das Ergebnis dieser Abfrage zurück, und die PHP-Laufzeit führt dann die WordPress-PHP-Dateien weiter aus … nun, das heißt, bis sie wieder Daten benötigt.

Dieses Hin und Her kann von ein paar Dutzend Mal bis zu ein paar Hundert Mal passieren. (Im letzteren Fall sollten Sie mit Ihrem Entwickler sprechen!) Deshalb ist dies ein großer Engpass.

Optimierung des Abfrage-Ergebnis-Zyklus

Das Optimierungsziel hier ist es, die Ausführungszeit von WordPress-Dateien durch PHP zu beschleunigen. Hier sind Datenbankabfragen problematisch. Sie benötigen in der Regel mehr Zeit, als nur einfachen PHP-Code auszuführen (es sei denn, Ihr Code macht etwas Unverschämtes).

Der offensichtliche Weg, dieses Problem zu beheben, besteht darin, die Anzahl der Abfragen zu reduzieren, die WordPress ausführen muss. Und das lohnt sich immer! Aber das ist nichts, womit der moderne WordPress-Server-Stack helfen kann.

Wir sind möglicherweise nicht in der Lage, die Anzahl der von WordPress gestellten Abfragen zu reduzieren, aber wir haben auch nicht alle Optionen. Es gibt noch zwei Möglichkeiten, wie uns der Stack dabei helfen kann, den Abfrage-Ergebnis-Zyklus zu optimieren. Es kann in erster Linie die Anzahl der an die Datenbank gestellten Abfragen reduzieren. Und für die Abfragen, die es in die Datenbank schaffen, kann die Ausführungszeit verkürzt werden.

Diese beiden Optionen sollen beide dasselbe bewirken: PHP so wenig wie möglich auf Ergebnisse aus der Datenbank warten lassen, wodurch WordPress selbst schneller wird.

Stack-Elemente für den Abfrage-Ergebnis-Zyklus

Schauen wir uns die verschiedenen Stack-Elemente an, die am Abfrageergebniszyklus beteiligt sind. Dieser Teil des Stapels ist weniger komplex. Aber es umfasst immer noch mehr als eine Komponente – nämlich den MySQL-Datenbankserver und den Objektcache.

MySQL-Datenbankserver

Vor ein paar Jahren bedeutete ein MySQL-Datenbankserver für alle dasselbe. Es war ein Server mit installiertem MySQL-Server. Aber die Dinge haben sich in den letzten Jahren stark verändert.

Verschiedene Gruppen waren nicht zufrieden damit, wie Oracle das MySQL-Projekt verwaltete. Also hat jede Gruppe es gegabelt und ihre eigene Version erstellt, die Sie stattdessen „einchecken“ können. Das Ergebnis ist, dass es jetzt mehrere MySQL-Datenbankserver gibt.

Der neue „offizielle“ MySQL-Server ist der MariaDB-Server. Es ist die von der Community entwickelte Version des MySQL-Servers. Die Community plant, die vollständige Kompatibilität mit dem MySQL-Serverprojekt aufrechtzuerhalten.

Eine weitere beliebte Alternative zu MySQL ist der Percona-Server. Im Gegensatz zu MariaDB ist Percona eher ein Zweig von MySQL. Seine Entwickler sind nicht gegen das MySQL-Projekt selbst; Sie wollen sich nur darauf konzentrieren, die Leistung von MySQL zu verbessern. Das MariaDB-Team führte später einige dieser Leistungsverbesserungen in das MariaDB-Projekt ein.

Am Ende des Tages können Sie das auswählen, das Sie bevorzugen. Es gibt keinen Leistungsunterschied zwischen einem Percona-Server und einem MariaDB-Server (zumindest für die meisten von uns). Beide performen besser als MySQL. Percona pflegt jedoch eine engere Kompatibilität mit dem Oracle-Projekt.

Was die Leistung beeinflusst, ist die Speicher-Engine , die die WordPress-Datenbank verwendet. Die Speicher-Engine steuert, wie der Datenbankserver die von ihm gespeicherten Daten verwaltet. Sie können auch eine andere Speicher-Engine pro Datenbanktabelle festlegen; Sie müssen nicht dasselbe für die gesamte Datenbank verwenden.

Ein Datenbankserver verfügt über mehrere Speicher-Engines. Wir werden uns nicht alle ansehen. Uns interessieren nur zwei: InnoDB und MyISAM.

Standardmäßig verwendet WordPress die standardmäßige MySQL-Datenbank-Engine. Vor MySQL 5.5 war diese Engine MyISAM. Wenn Sie eine kleine WordPress-Website betreiben, ist MyISAM in Ordnung. MyISAM stößt auf Leistungsprobleme, sobald eine Website größer wird. An diesem Punkt ist InnoDB die einzige Wahl für eine Datenbank-Engine.

Das einzige Problem mit InnoDB ist, dass es einige Optimierungen erfordert, um optimal zu funktionieren. Wenn Sie einen großen Datenbankserver betreiben, müssen Sie möglicherweise etwas anpassen. Zum Glück für uns gibt es ein Tool, das dabei hilft.

MySQLTuner ist ein kleines Skript, das Ihren Datenbankserver analysiert. Es erstellt einen Bericht und gibt Ihnen Tuning-Empfehlungen.

Objekt-Cache

Die Hauptarbeit bei der Optimierung des Abfrageergebniszyklus liegt beim Objektcache. Die Aufgabe des Objektcaches besteht darin, Daten zu speichern, deren Abruf oder Generierung zeitaufwändig ist. Wie Sie sich vorstellen können, sind Datenbankabfragen ein perfekter Kandidat.

WordPress verwendet den Objekt-Cache häufig. Angenommen, Sie verwenden get_option , um eine Option aus der Datenbank abzurufen. WordPress fragt die Datenbank nur einmal nach dieser Option ab. Es wird es nicht erneut abfragen, wenn jemand es das nächste Mal braucht.

Stattdessen holt WordPress das Abfrageergebnis aus dem Objektcache. Dies ist ein proaktiver Schritt, den WordPress unternimmt, um die Anzahl der erforderlichen Datenbankabfragen zu reduzieren. Aber es ist keine narrensichere Lösung.

Während WordPress sein Bestes tut, um den Objekt-Cache zu nutzen, muss ein Plugin oder Design dies nicht tun. Wenn ein Plugin oder Theme viele Datenbankabfragen macht und die Ergebnisse nicht zwischenspeichert, kann der Stack nichts dagegen tun.

In solchen Fällen kommen die meisten Datenbankabfragen von WordPress selbst. Sie werden also große Vorteile aus der in WordPress integrierten Verwendung des Objektcaches ziehen. Deshalb ist es ein wichtiges Element des modernen WordPress-Server-Stacks.

Nun, ein Problem mit dem Objekt-Cache besteht darin, dass er die gespeicherten Daten nicht standardmäßig speichert. Es speichert nur Daten im Speicher, während PHP alle WordPress-Dateien ausführt. Aber sobald der PHP-Prozess beendet ist, werden alle Daten, die er im Speicher gespeichert hat, gelöscht.

Das ist überhaupt nicht ideal. Ein Objekt-Cache kann lange Zeit gültig bleiben, daher möchten Sie ihn nicht auf eine einzelne Anfrage beschränken. Die Lösung besteht darin , einen persistenten Objektcache zu verwenden .

Ein persistenter Objekt-Cache kommt oft in Form eines Plugins daher. Dieses Plugin würde das Drop-in object-cache.php verwenden, um seine Arbeit zu erledigen. Mit diesem Drop-in können Plug-in-Autoren das Standardverhalten des Objektcaches ändern.

Die Plugins verbinden dann den Objekt-Cache mit einem persistenten Datenspeicher. Sie tun dies, indem sie die Abruf- und Speicherfunktion des Standardobjektcaches ersetzen. Anstatt Daten im Speicher zu speichern und abzurufen, übernimmt der Objektcache dies aus diesem Speicher.

Plugins für den persistenten Objekt-Cache

Heutzutage gibt es zwei beliebte Datenspeicheroptionen für das persistente Objekt-Caching:

• Speichercache (Plugin)
• Redis (Plugin)

Beide Datenspeicher verwenden RAM für die Speicherung, was sie blitzschnell macht. Tatsächlich ist ihre Leistung mit der des Standardobjektcaches vergleichbar.

Das einzige Problem ist, dass sie nicht auf Servern vorinstalliert sind. Und ihre PHP-Erweiterung (die bei Redis optional ist) auch nicht. Sie müssen eines installieren, bevor Sie das entsprechende WordPress-Plugin verwenden können.

Welche sollten Sie installieren? In der Praxis gibt es beim Objekt-Caching keinen großen Unterschied zwischen den beiden. In der Vergangenheit war die beliebte Option Memcached. Dies hat sich in den letzten Jahren geändert. Redis hat viele Funktionen hinzugefügt, die es zur ersten Wahl für das Zwischenspeichern von Objekten gemacht haben.

Holen Sie sich Ihren eigenen modernen WordPress-Server

Wie bekommt man also einen eigenen Server? Der naheliegende Weg ist, eines von einem erstklassigen WordPress-Hosting-Unternehmen zu bekommen. Diese Unternehmen wollen an der Spitze des WordPress-Hosting-Geschäfts bleiben, was sie dazu motiviert, die neuesten Durchbrüche und Technologien zu übernehmen.

Aber was, wenn Sie einen wollen, ohne die Bank zu sprengen? Ein paar Tools stehen allen zur Verfügung, die es lieber selbst machen und weniger für das Hosting bezahlen möchten. Schauen wir sie uns an.

DebOps für WordPress

DebOps für WordPress ist ein Tool, das ich entwickelt habe, um jedem beim Aufbau eines modernen WordPress-Servers zu helfen. Seine Mission ist es, den modernen WordPress-Server-Stack für jeden in der Community verfügbar zu machen. Deshalb versuche ich, es so einfach wie möglich zu machen. Sie benötigen keine Systemadministrationskenntnisse, um es zu verwenden.

DebOps für WordPress konfiguriert einen Server wie folgt:

• HHVM (bis PHP 7 es in ein offizielles Linux-Repository schafft)
• MariaDB
• nginx
• Redis
• Lack

Das Tool kann mehr als nur einen Server mit den neuesten Technologien konfigurieren. Es kümmert sich auch um die Sicherung des Servers für Sie. Dies ist etwas, das Leute oft übersehen, wenn sie ihren eigenen Server verwalten.

EasyEngine

EasyEngine ist ein Befehlszeilentool, mit dem Sie eine WordPress-Website auf einem Server einrichten können. Das Tolle an EasyEngine ist ihre Flexibilität: Sie können damit fast jede Kombination von Servertechnologien einrichten, die wir uns bisher angesehen haben.

Beispielsweise können Sie damit einen Server entweder mit HHVM oder PHP 7 einrichten. Sie können zwischen Memcached und Redis für Ihren persistenten Datenspeicher wählen. Außerdem können Sie Administrator-Tools wie phpMyAdmin installieren.

Es bietet auch eine Vielzahl von Optionen, wenn es eine WordPress-Website erstellt. Sie können ihm mit einem Plugin oder nginx sagen, dass er eine Website mit einem HTTP-Cache einrichten soll. All diese Flexibilität ist der Grund, warum EasyEngine so ein beliebtes Tool ist.

Gitter

Trellis ist ein von Roots entwickeltes Tool. Wie DebOps konfiguriert es den Server mit einem bestimmten Satz von Servertechnologien:

• MariaDB
• Zwischengespeichert
• nginx
• nginx-HTTP-Cache (optional)
• PHP7

Eine Sache, die man über Trellis wissen sollte, ist seine Beziehung zu Bedrock, einem anderen Tool, das von Roots entwickelt wurde. Bedrock ist ein Musterbeispiel für die Strukturierung einer WordPress-Website nach den „Twelve-Factor App“-Prinzipien.

Das Roots-Team hat Trellis erstellt, um Benutzern die Konfiguration eines Servers zu ermöglichen, der WordPress-Websites mit Bedrock-Struktur verwendet. Sie können es nicht mit einer normalen WordPress-Installation verwenden, also denken Sie daran.

Die Zeiten haben sich geändert

Wie Sie sehen können, hat ein WordPress-Server heute viel mehr bewegliche Teile! Aber das muss kein Grund zur Verzweiflung sein. Es ist nicht so schlimm, wie es aussieht, weil Sie nicht immer alle Teile verwenden müssen.

Aus diesem Grund wird in diesem Artikel so viel darüber diskutiert, wie diese Teile zusammenarbeiten. Der Punkt ist, Sie zu befähigen, Ihre eigenen Entscheidungen zu treffen. Verwenden Sie dieses Wissen, um zu entscheiden, welche Teile Sie wann verwenden müssen. Auf diese Weise haben auch Sie eine schnelle WordPress-Website.