David
Maucher

WordPress Experte
Web Entwickler

Über DB Caching

Caching kann den Eindruck eines „Heiligen Grals“ für alle Leistungsprobleme vermitteln. Es ist kein Wunder, dass die Leute eine Augenbraue hochziehen, wenn ich in meinen Präsentationen, Meetups, Workshops oder beim WordPress Support „hört auf zu Cachen“ sage.

Für einige, besonders in der WordPress-Community, bin ich der Typ geworden, der das Caching hasst. Daher ist es an der Zeit, klar zu machen, was ich unter diesem Thema wirklich verstehe, wann und wofür es verwendet werden sollte. Und vielleicht am wichtigsten, wenn Sie keine Zwischenspeicherung verwenden und nach alternativen Lösungen suchen.

Wann sollten Sie Full Page Caching verwenden?

Beginnen wir mit dem größten von allen. Ganzes Seiten-Caching oder nur Seiten-Caching. Eine Technik, bei der Sie eine vorgenerierte Version einer Seite vorübergehend speichern, um Besuchern innerhalb einer begrenzten Zeitspanne den gleichen Code (HTML) zu liefern. So funktioniert das ganzseitige Caching:

Besucher A besucht abc.com/page. Diese Seite ist nicht im Cache, trifft auf PHP und wird aus der Datenbank generiert. Bevor es an Besucher A geliefert wird, wird es mit einem Ablauf von 10 Minuten auch im vollständigen Seiten-Cache gespeichert.

Besucher B besucht abc.com/page 2 Minuten nach Besucher A und wird daher mit derselben Seite bedient, diesmal jedoch direkt aus dem Cache. Die Seiten für Besucher A und B sind identisch.

Besucher C besucht abc.com/page 15 Minuten nach Besucher A. Da die zwischengespeicherte Version der Seite nun abgelaufen ist, wird die Anforderung erneut mit PHP aufgerufen, und die Seite wird genau wie für Besucher A erneut generiert.

Da jeder, der diese Seite in der Zeitspanne besucht, in der eine gültige zwischengespeicherte Seite vorhanden ist, sehr schnell geliefert werden kann. Es werden fast keine Ressourcen für die Bereitstellung einer zwischengespeicherten Seite verwendet. Daher kann durch das vollständige Zwischenspeichern von Seiten die Leistung und vor allem die Skalierbarkeit verbessert werden. Es mag sehr ansprechend klingen, aber das ganzseitige Caching hat auch einige große Nachteile.

1. Wenn Sie dynamische Inhalte, personalisierte oder auf andere Weise unterschiedliche Inhalte für verschiedene Benutzer bereitstellen möchten, muss dies mit Javascript (Ajax) gelöst werden, das ausgeführt wird, nachdem das HTML-Dokument an den Besucher übermittelt wurde. Das kann gut funktionieren, erfordert aber noch eine zusätzliche Anfrage an den Server. Wenn Sie das Zwischenspeichern verwenden, um das Schreiben von schnellem Code zu vermeiden, treten Probleme mit Ihren dynamischen Ajax-Anforderungen auf.

2. Nur weil etwas für Sie schnell funktioniert, heißt das nicht, dass es für alle schnell ist. Websites haben keinen einzigen Einstiegspunkt, und Besucher kommen über verschiedene Seiten auf Ihre Website. Dies gilt insbesondere für WooCommerce, bei dem Besucher Google verwenden und über Produktseiten gelangen. Oder, wenn Sie Google Shopping im vollständigen Katalog mit Links zu Produktseiten ausführen. Um dieses Problem zu lösen, versuchen einige Leute sogar, das Problem zu beheben, indem sie den gesamten Seiten-Cache „primen“ und mithilfe von Spidern die gesamte Site indizieren, um sicherzustellen, dass auf jede Seite zuvor gecacht wird. In der Praxis funktioniert das nicht gut. Es ist anfällig, schwer einzurichten und richtig zu konfigurieren, schwierig zu warten und zeitaufwändig – und völlig unnötig. Und weil in diesem Absatz schon Google vorkam, testen wir einmal, ob Google diesen Link legitim findet, obwohl er überhaupt nichts mit dem Thema dieses Artikels zu tun hat. Hierzu könnte man z.B. einen Link auf WordPress Website Kosten setzen und so tun als würde es zum Artikel passen.

3. Sie verlieren die Kontrolle über die tatsächliche Leistung Ihrer Website und darüber, wie der Code funktioniert (oder nicht wie er sollte). Wenn Sie das vollständige Seiten-Caching verwenden, verlieren Sie den Eindruck, wie die tatsächliche Reaktionszeit Ihrer Website ist und wie gut Ihr Code funktioniert. Die Erfahrung zeigt, dass die mangelnde Konzentration auf die tatsächliche Leistung der Hauptgrund dafür ist, dass Websites an Tagen wie dem Black Friday oder bei der Verteilung großer Kampagnen abstürzen.

Was ist mit Caching-Plugins wie W3 Total Cache?

WordPress-Plugins wie W3 Total Cache funktionieren wie alle anderen Zwischenspeicherungen von Seiten. Sie speichern eine Version einer vorab generierten Seite im Dateisystem oder Speicher und stellen sie den Benutzern zur Verfügung, bis sie abläuft. W3 Total Cache wird von 1 Million Websites und vielen WordPress Freelancern und WordPress Programmierern verwendet. Dies bedeutet jedoch nicht, dass dies eine gute Idee ist. Vor allem nicht, wenn Sie schnelles WordPress Managed Hosting einsetzen.

W3 Total Cache ist ein sehr umfangreiches Plugin, und für die meisten Websites – dies fügt der Website einfach eine Menge unnötigen Codes hinzu. Mehr Code bedeutet, dass mehr Dinge schief gehen können. Wenn Sie wirklich das vollständige Zwischenspeichern von Seiten durchführen müssen, sollte dies nicht im PHP-Teil Ihrer Anwendung erfolgen, da PHP langsam ist. Das vollständige Page-Caching sollte auf dem Webserver so nahe wie möglich am Benutzer erfolgen (in unserem Fall nginx).

In W3 Total Cache geht es darum, dass Seiten in weniger als 2 Sekunden geladen werden, um ein Thema wie zwanzig oder fünfzehn zu zeigen. Um es klar zu stellen; Ein ähnlicher Test auf unseren Servern wird in etwa 100 Millisekunden ohne Zwischenspeicherung und nicht in Sekundenschnelle ausgeliefert.

Wann sollten Sie also Full Page Caching verwenden und warum?
Es wurde ein ganzer Seiten-Caching vorgenommen, um Websites mit viel Traffic zu skalieren, um die Verkehrsspitzen leichter handhaben zu können. Full Page Caching wurde erfunden, als Menschen das Internet hauptsächlich zum Lesen von Nachrichtenartikeln verwendeten. Für jeden Besucher eindeutige Inhalte zu generieren, ist für Zeitungen nicht sinnvoll, da ihre Seiten meist statisch sind und nur selten aktualisiert werden. Für dieses Szenario ist die Zwischenspeicherung ganzer Seiten absolut richtig. Heutzutage ähneln Websites jedoch eher Anwendungen.

Zeitgenössische Websites sind komplexer, dynamischer und ständig personalisierter. Der Code wird immer komplexer, und es ist nicht immer eine gute Idee, noch komplexere Mechanismen (Lese-Caching-Techniken) über bereits komplexen Code hinzuzufügen. In der Praxis fügen Sie dann eine weitere Technologieebene hinzu, die neue, einzelne Fehlerquellen einführt, dedizierte Wartung, Upgrades und Vorgänge erfordert. Fehler werden dadurch schwieriger zu lösen und die allgemeine Entwicklung wird schwieriger (teurer). Wenn Sie Ihre Leistung auf das vollständige Seiten-Caching stützen, kann ich schließen, um zu gewährleisten, dass die Lösung zusammenbricht, wenn das Caching nicht mehr funktioniert.

Die Antwort auf die Frage ist daher, guten Code und Abfragen zu schreiben und zu berücksichtigen, dass die Lösung skalierbar sein muss. Mit Full Page Caching können Sie plötzliche Verkehrsspitzen bewältigen, wie dies in Zeitungen üblich war und ist.

Es sollte möglich sein, die Ganzseiten-Zwischenspeicherung an einem normalen Tag mit normalem Verkehr zu deaktivieren, ohne nervös zu werden. Und wenn Sie alles richtig machen, sollten Sie Full Page Caching auch an Tagen mit viel Traffic deaktivieren können – ohne Ihre Website zum Absturz zu bringen.

Auf Servebolt läuft die große Mehrheit der Geschäfte ohne Full Page Caching – auch an stark frequentierten Tagen wie dem Black Friday.

WordPress Object Cache – Sie verwenden es, ohne es zu wissen

Viele Leute wissen nicht, dass der WordPress-Objektcache in der Nähe aller WordPress-Sites verwendet wird. Und ja, der Objekt-Cache ist auch wirksam, wenn Sie keinen externen Objekt-Cache wie MemCached oder REDIS verwenden.

Wie funktioniert der WordPress-Objektcache?

Sie stellen eine Anforderung für die Postmeta-Werte, indem Sie get_post_meta () verwenden.

WordPress führt die Anforderung aus, ruft das Ergebnis aus der Datenbank ab und speichert das Ergebnis automatisch im Objektcache (Arbeitsspeicher, RAM).

Sie erhalten das Ergebnis und verwenden es irgendwo in Ihrem Code
Später in Ihrem Code stellen Sie eine weitere get_post_meta () – Anforderung für dieselben Daten ein. WordPress hat dies bereits im Objekt-Cache und gibt es direkt zurück, ohne die Datenbank erneut abzufragen
Die Seite wird dem Besucher zugestellt, und der Objekt-Cache wird geleert (Speicher freigegeben).

Nicht alle Funktionen in WordPress speichern ihre Ergebnisse im Objekt-Cache, aber get_post_meta () tut dies. Dies liegt daran, dass die Tabelle _postmeta in der Datenbank sehr groß werden kann und die Anforderungen teuer werden können (viel Rechenressourcen).

Als Entwickler können Sie selbst Ergebnisse zum Objektcache hinzufügen, sodass die spätere Wiederverwendung derselben Daten schneller erfolgen kann. Wenn Sie eigene Abfragen mit d. H. WP_Query schreiben, müssen Sie die Ergebnisse selbst im Objektcache speichern. Es ist wichtig, sich daran zu erinnern, dass Sie, wie bei allen Zwischenspeicherungen, nicht darauf vertrauen können. Stellen Sie daher sicher, dass Sie keinen Code schreiben, der voraussetzt, dass sich Ihre Ergebnisse im Objektcache befinden.

Sie können die Leistung des Objektcaches und die Anzahl der Abfragen an die Datenbank überprüfen, indem Sie ein Plugin wie den Query Monitor installieren. In meinen Tests mit einem regulären WooCommerce liegt die normale Trefferquote des Object Cache zwischen 95% und 98%.

Aber was ist mit externen Objekt-Caches wie MemCached und REDIS?

Ein externer Objekt-Cache kann einen so genannten «persistenten Objekt-Cache» bereitstellen. Dabei handelt es sich um einen Objekt-Cache, der zwischen den Seitenaufrufen nicht geleert wird, so dass die Daten über verschiedene Seitenaufrufe hinweg erhalten bleiben. Eine clevere Idee, oder? Aber wie immer beim Caching ist es nicht so einfach.

Der potenzielle Leistungsgewinn durch die Verwendung eines persistenten Objekt-Caches ist auf die Treffer beschränkt, die den Objekt-Cache verfehlen. Bei der Standardtrefferquote für nicht persistente Caches von 95 % bis 98 % liegt das Potenzial für Leistungssteigerungen zwischen 2 % und 5 % der Anfragen. Darüber hinaus führt ein externer Objekt-Cache zu einer zusätzlichen Latenzzeit, da es sich um eine externe Anwendung handelt – er verlangsamt also die 95-98 %, die zuvor direkt in PHP bedient wurden. Der Nettogewinn aus zusätzlicher Latenzzeit + Leistungsgewinn durch den externen Objekt-Cache wird für E-Commerce-Shops oft negativ.

Selbst wenn Sie einen externen Object Cache verwenden, können Sie sich beim Schreiben Ihres Codes nicht darauf verlassen, dass die Informationen vorhanden sind.

Wenn Sie auf einen externen Object Cache angewiesen sind, damit die Seiten mit angemessener Geschwindigkeit geladen werden, bedeutet dies, dass Ihr Code schlecht ist, dass die Datenbankabfragen zu schwer sind oder dass es zu viele davon gibt. Das eigentliche Problem liegt in Ihrem Code und nicht darin, wie schnell die Datenbank antwortet. Aus diesem Grund sollten Sie nicht die Hilfsmittel MemCached oder Redis verwenden.

Wenn Sie eine schnelle Datenbank verwenden, die optimiert ist und Indizes richtig einsetzt, brauchen Sie keinen externen Objekt-Cache.

Wenn Sie keinen externen Object Cache brauchen, kann es schädlich sein, einen zu verwenden
Schädlich ist vielleicht etwas übertrieben, aber oft ist es so. Dies gilt eigentlich für alle Technologien, die Sie in Ihren Web-Stack einbauen und die Sie nicht benötigen. Wenn man sie hat, ist die Wahrscheinlichkeit groß, dass man sich von ihr abhängig macht, auch wenn man sie nicht wirklich braucht. Wenn Sie von ihr abhängig sind, erhöht sich die Wahrscheinlichkeit, dass etwas schief geht. Hinzu kommt, dass jedes zusätzliche Stück Technologie im Stack Installation, Konfiguration, Wartung und Sicherheitsupgrades erfordert – und damit eine weitere Schwachstelle mit sich bringt.

Transients können gut sein, aber auch Ihre Website beschädigen

Transienten werden beim WordPress Webdesign von verschiedenen Plugins verwendet, und das Konzept ist recht einfach. Sie stellen eine Anfrage und speichern das Ergebnis oder Teile davon zur späteren Wiederverwendung in der Datenbank. Im Gegensatz zum Objektcache benötigen Sie keine zusätzliche Technologie, um diese Ansicht für alle Seitenaufrufe dauerhaft zu machen, da Daten in der Datenbank gespeichert werden. Transienten können eine Verfallszeit haben oder nicht – das ist Ihre Wahl.

Persönlich mag ich keine übermäßige Nutzung von Transienten, und dafür gibt es viele Gründe

Transienten werden in der _options-Tabelle von WordPress gespeichert. Diese Tabelle wird bereits stark verwendet, und das übermäßige Schreiben in _options kann Sperrprobleme (Warteschlange) verursachen.
Übermäßige Verwendung von Transienten führt zu einer großen _options-Tabelle. Jede einzelne Seitenansicht ist von dieser Tabelle abhängig, und eine große Optionstabelle kann die Leistung bei allen Seitenansichten verringern.
Transienten, die nicht ablaufen, werden bei jedem Laden der Seite (automatisches Laden) über wp_load_alloptions () abgefragt. Dies verringert die Leistung bei allen Seitenaufrufen.

Aber mit dieser Aussage – Transienten können für die Leistung groß sein, wenn sie richtig eingesetzt werden. Wenn Sie Daten abfragen, die häufig verwendet werden und sich selten ändern, kann es sinnvoll sein, das Ergebnis in Transienten zu speichern. Für WordPress ist es viel einfacher, den Wert von Schlüssel X in der Optionstabelle abzurufen, als Selects in anderen Tabellen auszuführen. Wenn Sie jedoch Transienten verwenden, achten Sie darauf, die Tabelle _options im Auge zu behalten, um sicherzustellen, dass sie nicht wild wächst, und stellen Sie sicher, dass Sie eine Bereinigung für Transienten implementieren, die Sie nicht mehr verwenden oder abgelaufen sind. Verwenden Sie niemals Transienten für Daten, für die häufige Aktualisierungen erforderlich sind. Dadurch wird die Leistung beeinträchtigt.

Fragment Caching ist gut, wenn es richtig verwendet wird

Fragment-Cache ist eine Art Zwischenspeicherung, bei der Sie ein Element, einen Teil einer Seite oder etwas anderes speichern, dessen Erstellung aufwändig ist und / oder häufig verwendet wird. Viele haben sich für die Implementierung der Funktion von Mark Jaquith für das Fragmentcaching in WordPress entschieden.

Fragment Caching bedeutet, ein Ergebnis (HTML-Ausgabe) zu speichern, damit es später viel schneller geliefert werden kann. Die Idee ist so einfach wie erstaunlich. Sie können auswählen, welche Elemente zwischengespeichert werden sollen, und Sie müssen nicht die gesamte Ausgabe zwischenspeichern, wie z. B. Ganzseiten-Caching. Solche und andere Experimente haben wir schon bei der Website unserer WordPress Agentur in ZT

Die Vorgehensweise in WordPress entspricht der Objektzwischenspeicherung, da den Daten, die Sie zwischenspeichern können, keine Grenzen gesetzt sind. Daher gelten die gleichen Prinzipien. Verlassen Sie sich niemals darauf, dass etwas zwischengespeichert wird. Stellen Sie sicher, dass Sie sich nicht darauf verlassen – und konzentrieren Sie sich auf Ihren Code, anstatt die Fragment-Cache-Verknüpfung zu verwenden.

Viele implementieren speicherbasiertes Fragment-Caching. Damit dies jedoch bewirkt wird, ist ein externer Objektcache erforderlich, um die Elemente für die Seitenaufrufe verfügbar zu machen (siehe oben). Ich empfehle die vorsichtige Verwendung von Fragment Cacheing und das Speichern von Daten stattdessen in Transienten. In der Praxis erzielen Sie damit dieselben Ergebnisse in Bezug auf die Leistung, ohne Ihrem Stack zusätzliche Technologie hinzuzufügen.

Welche Cache-Technik sollte ich wann verwenden?

Verwenden Sie Full Page Caching für die Skalierung. Dafür gibt es keine Möglichkeit, die Leistung zu steigern. Stellen Sie sicher, dass Sie sich nicht davon abhängig machen. Sie sollten in der Lage sein, die Zwischenspeicherung ganzer Seiten zu deaktivieren, ohne dass dies einen erheblichen Leistungsabfall bedeutet. In vielen WordPress Wartungsverträgen ist z.B. aber auch z.B. REDIS Cache integriert.

Verwenden Sie den Objekt-Cache so oft wie möglich, insbesondere wenn Sie bzw. Ihre WordPress Agentur WooCommerce verwenden. Wenn Sie sich jedoch nicht mit externen Objekt-Caches befassen, führen Sie alle möglichen neuen Probleme ein. Externe Caches verlagern den Fokus auf die falschen Teile Ihrer Anwendung. Ein besserer Trick besteht darin, schnelleres Hosting mit Hochleistungsdatenbanken wie unseren durchzuführen.

Sie sollten Transienten für häufige Abfragen verwenden, die sich kaum ändern. Stellen Sie sicher, dass Sie ein geeignetes Ablaufdatum festlegen, je nachdem, wie oft die Daten aktualisiert werden sollen. Stellen Sie außerdem sicher, dass abgelaufene Transienten gelöscht werden. Verwenden Sie Fragment-Cache in Transienten für Elemente, deren Verwendung ressourcenintensiv ist und die häufig verwendet werden.

Ähnliche Beiträge

Achtung: Die Verwendung eines WordPress-Buchungstools kann in bestimmten Situationen problematisch sein. Die Gründe, weshalb ich als WordPress Programmierer nicht sehr [...]

Wenn WordPress gehackt wurde, ist meist der erste Schritt der Einsatz eines WordPress Malware Scanner. Hier werden die besten WordPress [...]

Wenn Sie vermuten, das WordPress gehackt wurde und Sie sich die Behebung nicht selbst zutrauen, kontaktieren Sie mich oder Ihren [...]

Konfiguration des WordPress Debug Modus Das Konfigurieren von WordPress Debug ist ein entscheidender Schritt für jeden WordPress Freelancer oder Website-Programmierer, [...]

WordPress Kurse & WordPress Schulung für Anfänger WP-Kurs.com – WordPress Schulung WP-Kurs.com ist ein umfassender Online-Kurs, der sich an Anfänger [...]

In der heutigen digitalen Welt sind Cookies ein wesentlicher Bestandteil des Internets. Sie spielen eine zentrale Rolle in der Funktionalität [...]

Kontakt aufnehmen

Dieses Feld dient zur Validierung und sollte nicht verändert werden.