Willkommen zu einem neuen Kapitel in unserer WordPress Caching-Reihe, in dem wir lernen, wie WordPress Caching funktioniert. Bevor wir diesem Thema auf den Grund gehen, stellen Sie bitte sicher, dass Sie jedes der vorherigen Themen (aus dieser Reihe) sorgfältig gelesen haben, da dieses Kapitel das Wissen aus ihnen verwendet. Lassen Sie uns zunächst über die beiden wichtigsten verfügbaren Arten von Caching-Protokollen sprechen, die auf dem Client-Server-Modell basieren:
- Clientseitiges Caching und
- Serverseitiges Caching
Clientseitiges Caching
Eine Website enthält viele nicht textuelle, statische Daten wie Bilder, CSS- und Javascript-Dateien. Sobald sie heruntergeladen wurden, ist Ihr Browser intelligent genug, um sie nicht jedes Mal erneut herunterzuladen, wenn Sie die F5-Taste drücken. Es dient lediglich diesen Daten aus dem lokalen Cache – dh den zwischengespeicherten Daten, die auf der Festplatte Ihres Computers gespeichert sind. Aus diesem Grund empfiehlt es sich, den Cache Ihres Browsers von Zeit zu Zeit zu leeren – das spart viel Platz und verbessert die Leistung.
Dieser Prozess der Wiederverwendung der zwischengespeicherten Daten vom Computer des Clients (oder vom Client-Ende) wird als clientseitiges Caching bezeichnet und wird von fast jeder modernen Website verwendet und von jedem Browser unterstützt. Clientseitiges Caching verhindert Datenredundanz (dh immer wieder dieselben Daten herunterladen) und spart somit viele Serverressourcen und vor allem Zeit!
Serverseitiges Caching
Serverseitiges Caching umfasst alle verschiedenen Caching-Protokolle, die beim WordPress-Caching verwendet werden. Sie umfassen Folgendes:
- Seiten-Caching
- Caching von Datenbankabfragen
- Objektbasiertes Caching
- Opcode-Caching
WordPress verwendet diese vier wichtigsten serverseitigen Caching-Protokolle. Wir werden uns jeden von ihnen einzeln ansehen und sehen, wie das Caching jedes von ihnen viel kostbare Rechenzeit sparen und so Ihre Website beschleunigen kann.
Seiten-Caching
Seiten-Caching ist das einfachste aller Caching-Protokolle und ich wette, Sie wissen bereits darüber Bescheid. Es bezieht sich einfach auf den Vorgang des Speicherns der dynamisch generierten HTML-Dateien auf der Festplatte oder im Arbeitsspeicher (RAM) des Servers (allgemein als „Cache“ bekannt) und deren Bereitstellung aus dem Cache (dh Wiederverwendung zuvor generierter Daten), wenn eine Anfrage gestellt wird. . Dies spart den Aufwand für die Ausführung von PHP-Code und MySQL-Datenbankabfragen.
Datenbank-Caching
Das erste, was Sie über Datenbanken wissen sollten, ist, dass sie riesig und ressourcenhungrig sind. Sie sind im wahrsten Sinne des Wortes das Herz jedes Unternehmens – sei es online oder anderweitig. Gleiches gilt für WordPress. Das Ziel einer Datenbank ist es, Daten effizient zu speichern, zu aktualisieren und bereitzustellen. Da sie normalerweise sehr groß sind, braucht jede Abfrage Zeit (normalerweise in der Größenordnung von einigen hundert Mikrosekunden). Bessere Hardware, schnellere Generierung der Abfrageergebnisse. Denk darüber nach. Da WordPress stark von seiner Datenbank abhängig ist, führt es hin und wieder eine Abfrage durch. Und wenn die Daten in der Datenbank nicht geändert werden, ist das Durchführen von Abfragen zum Abrufen derselben Daten ähnlich wie das wiederholte Herunterladen derselben Bilder immer wieder – wie unter Clientseitiges Caching beschrieben. Daher ist es sinnvoll, die Ergebnisse einer Abfrage im lokalen Speicher zu speichern, oder? Dieses Speichern der Ergebnisse von Datenbankabfragen im lokalen Speicher wird Datenbank-Caching genannt und ist einer der grundlegenden Faktoren beim WordPress-Caching.
Sobald die Datenbank jedoch aktualisiert wird (z. B. wenn ein Beitrag aktualisiert oder veröffentlicht oder ein Kommentar gesendet wird), ist es sehr wichtig, dass der zuvor gespeicherte Datenbank-Cache gelöscht wird und die Ergebnisse der Datenbankabfrage erneut zwischengespeichert werden. Dies ist nicht redundant, da es hilft, irrelevante oder fehlerhafte Datenbankabfrageergebnisse zu vermeiden.
Objekt-Caching
WordPress verfügt über ein internes Caching-System, das mehrere Subsysteme umfasst (dh die Caching-API, der Objekt-Cache und die Transient-API). Der WordPress-Kern ermöglicht es Plugins, dieses Caching-System zu steuern, um die Anzahl der Datenbankaufrufe zu reduzieren. Dies ist ein ziemlich fortgeschrittenes Thema und für den normalen Benutzer nicht ganz relevant.
Opcode-Caching
Ähnlich wie beim Datenbank-Caching, bei dem es darum geht, die Anzahl der Datenbankabfragen zu reduzieren, bezieht sich das Opcode-Caching auf das Speichern des kompilierten PHP-Codes zwischen jeder Anfrage. Wenn Sie sich eine PHP-Datei ansehen, werden Sie feststellen, dass der Code eigentlich eine Liste von Anweisungen für den Compiler ist. PHP ist eine objektorientierte Programmiersprache und hat seine Vorteile von Anfang an! Damit ein PHP-Code ausgeführt werden kann, muss der PHP-Compiler den Code zuerst kompilieren und den ausführbaren Code für die Ausführung durch den Webserver generieren. Die Ausgabe des PHP-Compilers für mehrere Ausführungen zwischenzuspeichern, darum geht es beim Opcode-Caching. Auch hier handelt es sich um interne Dinge – Dinge, über die Sie sich keine großen Sorgen machen sollten!
Lokaler Speicher – Primär versus Sekundär
Um serverseitiges Caching jeglicher Form zu implementieren, versteht es sich, dass die Daten im lokalen Speicher gespeichert werden müssen. Der Begriff „lokaler Speicher“ kann zweierlei bedeuten. Einer ist die Festplatte des Servers und der andere ist der Primärspeicher des Servers – also der Arbeitsspeicher.
RAM, das für Random Access Memory steht, ist eine Form des flüchtigen Speichers und ist um Größenordnungen schneller als Festplatten, die eine Form nichtflüchtiger Sekundärspeicher sind. Es ist auch teurer. Das wissen Sie natürlich alle.
Wo Sie die zwischengespeicherten Daten speichern, macht einen großen Unterschied. Wenn es sich auf einer Festplatte befindet, ist es definitiv langsamer, als wenn es in einem RAM gespeichert ist. Auch hier spielt die Geschwindigkeit der HDD eine Rolle. Server-Festplatten reichen von 7.200 U/min bis 15.000 U/min und können unterschiedliche RAID-Level haben – RAID 0 ist das schnellste und unsicherste, RAID 4 ist die richtige Balance. Du hast auch SSDs. Daher hat der Ort der zwischengespeicherten Daten einen schwerwiegenden Einfluss auf die Geschwindigkeit.
Für Leute auf Shared-Hosting-Servern haben Sie keine andere Wahl, als sie auf der Festplatte zu speichern. Für Leute, die einen eigenen dedizierten Server oder VPS betreiben, haben Sie zusätzlich die Möglichkeit, den Cache in Ihrem primären Speicher zu speichern, was wiederum mit großer Sorgfalt durchgeführt werden muss – eine falsche Konfiguration kann zu Instabilität führen (Arbeitsspeichermangel usw.) und häufige Serverabstürze.
Abschluss
Nachdem Sie nun die verschiedenen WordPress-Caching-Protokolle gut verstanden haben, kommen wir zum Kernstück unserer Beitragsserie – So implementieren Sie WordPress-Caching.
Wenn Sie Fragen oder Verbesserungsvorschläge für dieses Kapitel haben, können Sie diese gerne stellen oder teilen – wir freuen uns über Ihre Meinung!