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_Cache
Klassen 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.php
und / 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_Query
hat 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_Query
geschieht in update_meta_cache
für Meta und in update_object_term_cache
fü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_cache
Es 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_Query
Argumente schließlich
Was 'update_post_meta_cache'
und 'update_post_term_cache'
tun , wenn auf false
Wordpress 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 false
eine 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
.
wp_reset_postdata()
zurücksetzenglobal $post
und 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.