Über DB Caching

Wie funktioniert das Caching in WordPress?

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 oder Workshops „Caching aufhören“ 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.

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 verwendet. Dies bedeutet jedoch nicht, dass dies eine gute Idee ist. Vor allem nicht, wenn Sie schnelles 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%.

But what about external Object Caches like MemCached and REDIS?

An external Object Cache can provide what more specifically is called a “persistent Object cache”. That is an Object Cache that does not get flushed between page views, so it retains its data across different page views. Smart idea, right? But as usual with caching, it is not as simple as that.

The potential performance gain from using a persistent Object Cache is limited to the hits that miss the Object Cache. Using the default non-persistent cache hit rate of 95%-98%, the potential for performance gains is for between 2% and 5% of the request. In addition, an external object cache will add some extra latency because it is an external application – so it will slow down the 95-98% that were served directly in PHP before. The net gain from added latency + performance gain from external Object Cache often becomes negative for E-commerce stores.

Even if you use an external Object Cache, you can not trust that the information exists when writing your code.

If you are dependant on an external Object Cache to make pages load at decent speed, it means your code is bad, that database queries are too heavy, or that there are too many of them. The real problem is in your code, not how quick the database responds. That’s why you should not use the band aid MemCached or Redis.

If you use a fast database that is optimised and uses indexes correctly, you do not need an external Object Cache.

If you don’t need an external Object Cache, it can be harmful to use one
Harmful may be stretching it, but it often is. This really applies to all technology you include in your web stack, that you don’t need. If you have it, the chance for making yourself dependent on it is big, even if you really don’t need it. If you are dependent on it, you increase the chances for something to go wrong. In addition, every added piece of technology in the stack requires installation, configuration, maintenance, security upgrades – and introduces yet another single point of failure.

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

Transienten werden von WordPress und 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.

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.

Verwenden Sie den Objekt-Cache so oft wie möglich, insbesondere wenn Sie 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.

Jetzt unsere Preisliste downloaden!

Geben Sie einfach Ihre E-Mail Adresse ein und Sie erhalten sofort unsere aktuelle Preisliste per E-Mail zugesandt. Darin enthalten sind unsere Preise für:


Ihre E-Mail-Adresse wird nur für die Zusendung von Informationen verwendet und nicht an Dritte weitergegeben. Sie können die Informationen jederzeit wieder abbestellen.