Erklärung von update_post_ (meta / term) _cache

23

Ich habe einige Best Practices von 10up durchgelesen und sie erwähnen das Setzen dieser beiden Flags auf false in einer WP_Query (abhängig davon, was Sie abfragen):

  • 'update_post_meta_cache' => false: nützlich, wenn Post-Meta nicht verwendet wird.
  • 'update_post_term_cache' => false: nützlich, wenn Taxonomiebegriffe nicht verwendet werden.

Ich gehe davon aus, dass es so etwas nutzt, update_post_caches()aber ich bin mir nicht mal 100% sicher, was das bedeutet. Könnte jemand erklären, was diese beiden Flags in a bedeuten WP_Queryund wie nützlich sie sind? Je mehr Informationen, desto besser, da ich nicht viel darüber weiß, wie WordPress Dinge zwischenspeichert, aber auch eine gut durchdachte Antwort zu diesen beiden Flags akzeptabel ist.

post-meta terms cache customization core Howdy_McGee
quelle

Antworten:

30

Objektcache überall

WordPress versucht, die Anzahl der Datenbankabfragen so weit wie möglich zu reduzieren.

Wenn Sie beispielsweise vor dem Abfragen der Datenbank ein Meta- oder Taxonomiefeld abrufen, prüft WordPress, ob dieses bereits abgefragt und im Cache gespeichert wurde, und gibt es von dort zurück, anstatt die Datenbank abzufragen.

Der "Cache-Job" wird über WP_Object_CacheKlassen und wp_cache_*Funktionen ausgeführt (die Wrapper für diese Klassenmethoden sind.)

Wo der Cache lebt

Standardmäßig ist der "Cache" nichts anderes als eine globale PHP-Variable. Es bedeutet, dass es sich im Speicher befindet, aber auch, dass es bei jeder Anforderung verschwindet.

Über Dropins ( advanced-cache.phpund / oder object-cache.php) ist es jedoch möglich, eine benutzerdefinierte Methode zum Behandeln dieses Caches einzurichten .

Normalerweise werden diese Dropins verwendet, um eine Art Caching-Mechanismus einzurichten, der die einzelnen Anforderungen "überlebt".

Aus diesem Grund werden diese unter WP-Leuten als "Persistent Cache" -Plugins bezeichnet (auch wenn die Wörter "Cache" und "Persistent" außerhalb der Blase nicht viel Sinn ergeben).

Heutzutage sind Memcached oder Redis beliebte Optionen .

Durch die Verwendung von Plugins für "Persistenten Cache" können Sie die Anzahl der Datenbankabfragen drastisch reduzieren, da der Cache nicht bei jeder Anforderung aktualisiert wird.

Einige Beispiele

$foo = get_post_meta('foo', $post_id, true);
// a lot of code in the middle
$bar = get_post_meta('bar', $post_id, true);

Die beiden obigen Codezeilen lösen maximal eine Datenbankabfrage aus.

Wenn Sie ein benutzerdefiniertes Feld abfragen, werden alle Felder für diesen Beitrag aus der Datenbank abgerufen, über den Objektcache zwischengespeichert und nachfolgende Anforderungen rufen Daten aus dem Cache und nicht aus der Datenbank ab.

Dasselbe gilt für Taxonomiebegriffe. WordPress ruft alle Begriffe für eine Taxonomie einmal ab und gibt sie dann aus dem Cache zurück.

Objekt-Cache wird in WordPress sehr häufig verwendet. Nicht nur für Posts, Metawerte und Taxonomien, sondern auch für Benutzer, Kommentare, Themendaten ...

Was WP_Queryhat das alles zu tun?

Wenn Sie einige Posts über abfragen WP_Query, zieht WordPress sie standardmäßig nicht nur aus der Datenbank (oder aus dem Cache, wenn sie zwischengespeichert sind), sondern aktualisiert auch den Cache für alle benutzerdefinierten Felder und alle Taxonomien, die sich auf die abgerufenen Posts beziehen.

Wenn Sie also zum Beispiel anrufen get_the_terms()oder get_post_meta()Beiträge durchlaufen WP_Query, lösen Sie keine Datenbankabfrage aus, sondern ziehen Informationen aus dem Cache.

Schön, ist es nicht?

Nun ja, aber es ist mit Kosten verbunden.

Das Cache-Update "magic", das WordPress beim Abrufen von Beiträgen durchführt, WP_Querygeschieht in update_meta_cachefür Meta und in update_object_term_cachefür Taxonomien.

Wenn Sie sich den Quellcode dieser Funktionen ansehen, werden Sie feststellen, dass WordPress in jeder Funktion nur eine Datenbankabfrage durchführt, aber auch eine Menge Verarbeitung durchführt. Beispiel: update_object_term_cacheEs gibt 7 verschachtelteforeach Einträge. Wenn Sie viele Taxonomien haben und die Anzahl der Einträge pro Seite hoch ist, ist dies nicht sehr performant.

Über diese WP_QueryArgumente schließlich

Was 'update_post_meta_cache'und 'update_post_term_cache'tun , wenn auf falseWordpress zu Update - Cache für benutzerdefinierte Felder und Taxonomien bzw. zu verhindern.

In diesem Fall wird beim ersten Abfragen eines benutzerdefinierten Felds oder einer Taxonomie eine Datenbankabfrage ausgelöst und die Daten werden zwischengespeichert.

Lohnt es sich die Mühe?

Wie immer kommt es darauf an . Das Festlegen dieser Werte ist in den meisten Fällen falseeine gute Wahl, da unnötige Verarbeitungs- und Datenbankabfragen vermieden werden, wenn sie nicht benötigt werden, und der Cache ohnehin aktualisiert wird, wenn zum ersten Mal benutzerdefinierte Feld- / Taxonomiebegriffe erforderlich sind.

Wenn Sie jedoch auch nur einmal get_post_meta()während der Schleife anrufen get_the_terms()und alle (oder die meisten) von Posts unterstützten Taxonomien anrufen , wird die Cache-Aktualisierung trotzdem ausgelöst, und es besteht möglicherweise kein tatsächlicher Vorteil für Setzen Sie diese Abfrageargumente auf false.

gmazzap
quelle
Ordentlich! Wie immer wird Ihre Einsicht immer von GM geschätzt. Würden Transienten als "persistenter Cache" betrachtet? Wenn Sie also während einer WP_Query fortfahren möchten, müssen Sie den Objekt-Cache wp_reset_postdata()zurücksetzen global $postund zurücksetzen. Es hört sich so an, als würde bei einer benutzerdefinierten WP_Query ein neues zwischengespeichertes Objekt erstellt, aber beim Zurücksetzen müsste auch erneut abgefragt werden, um den ursprünglichen Cache zu erhalten. Oder ich komme im Zusammenhang mit dieser Frage zu weit.
Howdy_McGee
1
@Howdy_McGee Objekt-Cache und Post-Objekt sind nicht miteinander verbunden. Also wp_reset_postdata()nichts in Bezug auf Objekt-Cache. wp_reset_postdata()Nur globales Post-Objekt zurücksetzen, das ist eine weitere globale Variable, die niemals zwischengespeichert wird ... Transienten sind eine hybride Sache: Wenn Sie ein persistentes Cache-Plugin installiert haben, verwenden Sie dies transient, aber wenn Sie kein persistentes Cache-Plugin haben, dann transient Datenbank verwenden.
gmazzap
Ah, ich habe mich nur an die global variableVorstellung gehalten und angenommen, es handele sich um das global $postoder die globalen $wp_queryObjekte, danke für die Klarstellung!
Howdy_McGee
Auf einer Bemerkung am Rande , fields => 'ids'setzt beide Caches false. Ich nehme an, es macht Sinn , dass ein Object Cache nur auf Objekte funktioniert , aber ich dachte , ich würde nur eine Erwähnung machen: D
Howdy_McGee
3

Das Hauptinteresse hierbei ist die update_post_cachesFunktion. Es wird aufgerufen, nachdem WP_Query alle Posts aus der DB erhalten hat. Normalerweise möchten Sie die Posts zunächst anzeigen, was normalerweise bedeutet, dass die Begriffe und etwas basierend auf den Metadaten angezeigt werden. Daher fragt WP_Query standardmäßig die DB nach den Meta- und Termdaten ab, die sich auf die zurückgegebenen Posts beziehen und speichert es den Cache *. Diese Informationen sind in den von WP_Query zurückgegebenen Daten nicht explizit verfügbar. Wenn Sie jedoch die relevanten APIs aufrufen, um die Begriffs- und Metainformationen eines bestimmten Posts abzurufen, sind sie bereits im Speicher verfügbar und es ist nicht erforderlich, eine neue zu senden Abfrage an die DB.

Dies ermöglicht WordPress, den Aufwand für das Senden von Anforderungen an die Datenbank zu reduzieren, indem nur eine Anforderung gesendet wird, um die Informationen für alle Beiträge abzurufen, anstatt für jeden Beitrag eine Anforderung zu senden.

Im Moment kann ich kein nicht triviales Beispiel dafür finden, wann der Cache nicht aktualisiert werden soll. Ein triviales Beispiel ist es jedoch, wenn Sie nur eine Liste der Titel aller Beiträge wünschen. Dafür benötigen Sie keine Term- oder Metadaten.

* cache - Am wichtigsten ist hier der speicherbasierte Cache, in dem WP fast alles speichert, was es von der DB erhält, auch ohne dass ein Objekt-Caching-Plugin aktiv ist. Wenn Sie Objekt-Caching haben, werden die Informationen natürlich auch dort gespeichert.

Mark Kaplun
quelle