Explication de update_post_ (meta/term) _cache
Je lisais quelques meilleures pratiques de 10up et ils mentionnent la définition de ces deux indicateurs sur false dans WP_Query (selon ce que vous interrogez):
'update_post_meta_cache' => false: utile lorsque les méta-messages ne seront pas utilisés.'update_post_term_cache' => false: utile lorsque les termes de taxonomie ne seront pas utilisés.
Je suis en supposant que il utilise quelque chose comme update_post_caches() mais je ne suis même pas sûr à 100% de ce que cela signifie. Quelqu'un pourrait-il expliquer la signification de ces deux indicateurs dans un WP_Query et à quel point ils sont utiles? Plus il y a d'informations, mieux c'est, car je ne connais pas grand-chose à la façon dont WordPress met les choses en cache, mais une réponse bien pensée concernant ces deux drapeaux est également acceptable.
Cache d'objets partout
WordPress tente de réduire autant que possible le nombre de requêtes dans la base de données.
Par exemple, chaque fois que vous obtenez un champ méta ou un champ de taxonomie, avant d'interroger la base de données, WordPress vérifie si celui-ci a déjà été interrogé et stocké dans le cache et le renvoie à partir de cet emplacement au lieu d'interroger la base de données.
Le "travail en cache" est effectué via WP_Object_Cache CLASS ET LES FONCTIONS wp_cache_* (encapsulant les méthodes de cette classe).
Où cache cache
Par défaut, le "cache" n'est rien d'autre qu'une variable globale PHP. Cela signifie qu'il est en mémoire, mais cela signifie également qu'il disparaît à chaque requête.
Cependant, via les dropins (advanced-cache.php et/ou object-cache.php), il est possible de configurer un moyen personnalisé pour gérer ce cache.
Habituellement, ces dropins sont utilisés pour configurer une sorte de mécanisme de cache qui "survit" aux requêtes singulières.
Pour cette raison, parmi WP personnes, ils sont connus sous le nom de plugins "cache persistant" (même si en dehors de la bulle, les mots "cache" et "persistant" n'ont pas beaucoup de sens ensemble).
Les choix les plus populaires actuellement sont Memcached ou Redis .
Donc, en utilisant des plugins "cache persistant", vous pouvez réduire considérablement le nombre de requêtes de base de données, car le cache n'est pas mis à jour à chaque requête.
Quelques exemples
$foo = get_post_meta('foo', $post_id, true);
// a lot of code in the middle
$bar = get_post_meta('bar', $post_id, true);
Les 2 lignes de code ci-dessus déclencheront, au maximum, 1 interrogation de base de données.
En fait, lorsque vous interrogez un champ personnalisé, tous les champs de cette publication sont extraits de la base de données, mis en cache via le cache d'objets et les requêtes suivantes extraient les données du cache et non de la base de données.
Il en va de même pour les termes de taxonomie: WordPress extrait tous les termes d’une taxonomie une fois, puis les renvoie à partir du cache.
Le cache d'objets est très utilisé dans WordPress. Non seulement pour les posts, les méta-valeurs et les taxonomies, mais aussi pour les utilisateurs, les commentaires, les données de thème ...
Qu'est-ce que WP_Query a à voir avec tout ça?
Lorsque vous interrogez certaines publications via WP_Query, par défaut, WordPress les extrait non seulement de la base de données (ou du cache si elles sont mises en cache), mais aussi met à jour le cache pour tous les champs personnalisés et toutes les taxonomies liées aux publications extraites. .
Ainsi, lorsque vous appelez, par exemple, get_the_terms() ou get_post_meta() lors de la mise en boucle de messages obtenus via WP_Query, vous ne déclenchez pas de requête de base de données, mais extrayez des informations dans le cache.
Nice, ça ne l'est pas?
Eh bien, oui, mais cela a un coût.
La mise à jour du cache "magique" utilisée par WordPress lors de l'extraction de publications via WP_Query se produit dans update_meta_cache pour méta et dans update_object_term_cache pour taxonomies.
Si vous examinez le code source de ces fonctions, vous verrez que WordPress n’effectue qu’une requête de base de données dans chaque fonction, mais effectue également de nombreux traitements. Par exemple, dans update_object_term_cache il y a 7 niché foreach ... si vous avez beaucoup de taxonomies et que le nombre de posts par page est élevé, cela n’est pas très performant.
À propos de ces arguments WP_Query, enfin
Ce que 'update_post_meta_cache' et 'update_post_term_cache' font lorsqu'il est défini sur false consiste à empêcher WordPress de mettre à jour le cache pour les champs personnalisés et les taxonomies, respectivement.
Dans ce cas, la première fois qu'un champ personnalisé ou une taxonomie est interrogé, une requête de base de données est déclenchée et les données sont mises en cache.
Ça vaut la peine?
Comme d'habitude, la réponse est cela dépend . La plupart du temps, le fait de définir false sur ces valeurs est un bon choix, car il évite les requêtes inutiles en matière de traitement et de base de données, et le cache est mis à jour de toute façon lors de la première utilisation des termes de taxonomie/champs personnalisés.
Toutefois, si vous appelez, même une fois, get_post_meta() pendant la boucle et que vous appelez get_the_terms() pour toutes (ou la plupart) des taxonomies prises en charge par les publications, la mise à jour du cache est déclenchée de toute façon et il peut ne pas y avoir de modification réelle. avantage sur la définition de ces arguments de requête à false.
Le point d’intérêt principal ici est la fonction update_post_caches. Il est appelé après que WP_Query ait obtenu tous les articles de la base de données. Généralement, la raison pour laquelle vous voulez les publications en premier lieu est de les afficher, ce qui signifie généralement d'afficher les termes et quelque chose basé sur les métadonnées. WP_Query interrogera donc par défaut le DB pour les métadonnées et les données de terme associées aux publications renvoyées. et le stocke dans le cache *. Ces informations ne sont pas explicitement disponibles dans les données renvoyées par WP_Query, mais lorsque vous appelez les API pertinentes pour obtenir le terme et les métadonnées d'un message spécifique, elles seront déjà disponibles en mémoire et il ne sera pas nécessaire d'envoyer un nouveau message. requête à la base de données.
Ceci permet à wordpress de réduire le temps système lié à l'envoi de demandes à la base de données en n'envoyant qu'une seule demande pour obtenir les informations sur tous les articles au lieu d'envoyer une demande pour chaque article.
À l'heure actuelle, je ne trouve aucun exemple non trivial de la date à laquelle vous ne souhaitez pas que le cache soit mis à jour, mais un exemple trivial peut être si vous souhaitez simplement une liste des titres de tous les articles. Pour cela, vous n'avez pas besoin de terme ou de métadonnées.
* cache - Le plus important ici est le cache basé sur la mémoire dans lequel WP stocke presque tout ce qu'il obtient de la base de données, même sans aucun plug-in de mise en cache d'objet actif. Évidemment, lorsque vous avez des objets en mémoire cache, les informations y sont également stockées.