Je lisais certaines des meilleures pratiques de 10up et elles mentionnent la définition de ces deux indicateurs sur false dans un WP_Query (selon ce que vous interrogez):

• 'update_post_meta_cache' => false: utile lorsque la post-méta ne sera pas utilisée.
• 'update_post_term_cache' => false: utile lorsque les termes taxonomiques ne sont pas utilisés.

Je suppose qu'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 ce que ces deux drapeaux signifient dans a WP_Queryet leur utilité? Plus il y a d'informations, mieux c'est, car je ne sais pas grand-chose sur la façon dont WordPress met les choses en cache, mais une réponse bien pensée concernant ces deux indicateurs est également acceptable.

Cache d'objets partout

WordPress essaie de réduire autant que possible le nombre de requêtes de 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 recherche si celui-ci a déjà été interrogé et stocké dans le cache, et le renvoie à partir de là au lieu d'interroger la base de données.

Le "travail de cache" se fait via la WP_Object_Cacheclasse et les wp_cache_*fonctions (qui sont le wrapper des méthodes de cette classe)

Où vit la cache

Par défaut, le "cache" n'est rien de plus qu'une variable globale PHP. Cela signifie qu'il est en mémoire, mais signifie également qu'il disparaît à chaque demande.

Cependant, via des dropins ( advanced-cache.phpet / ou object-cache.php), il est possible de configurer une manière personnalisée de gérer ce cache.

Habituellement, ces dropins sont utilisés pour configurer une sorte de mécanisme de mise en cache qui "survit" aux demandes singulières.

Pour cette raison, parmi les gens WP, ce sont des 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 populaires de nos jours sont Memcached ou Redis .

Ainsi, en utilisant des plugins de "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 demande.

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 requête de base de données.

En fait, lorsque vous interrogez un champ personnalisé, tous les champs de cette publication sont récupérés 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.

La même chose se produit pour les termes de taxonomie, WordPress extrait une fois tous les termes d'une taxonomie, puis les renvoie du cache.

Le cache d'objets est très largement utilisé dans WordPress. Non seulement pour les publications, les méta-valeurs et les taxonomies, mais aussi pour les utilisateurs, les commentaires, les données de thème ...

Qu'est-ce que cela WP_Querya à voir avec tout cela?

Lorsque vous interrogez certains articles via WP_Query, par défaut, WordPress les extrait non seulement de la base de données (ou du cache s'ils sont mis en cache) mais met également à jour le cache pour tous les champs personnalisés et toutes les taxonomies liées aux articles extraits.

Ainsi, lorsque vous appelez, par exemple, get_the_terms()ou get_post_meta()pendant le bouclage de messages WP_Query, vous ne déclenchez en fait aucune requête de base de données, mais extrayez des informations du cache.

C'est bien, non?

Eh bien, oui, mais cela a un coût.

La mise à jour du cache "magique" que WordPress fait lorsque les messages sont via WP_Queryse produisent update_meta_cachepour les méta et les update_object_term_cachetaxonomies.

Si vous regardez le code source de ces fonctions, vous verrez que WordPress effectue une seule requête db dans chaque fonction, mais effectue également beaucoup de traitement. Par exemple, update_object_term_cacheil y en a 7 imbriquésforeach ... si vous avez beaucoup de taxonomies, et que le nombre de messages par page est élevé, ce n'est pas très performant.

À propos de ces WP_Queryarguments, enfin

Ce qui est fait 'update_post_meta_cache'et 'update_post_term_cache'ce qui est réglé sur falseest d'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 le coup?

Comme d'habitude, la réponse est que cela dépend . La plupart du temps, définir ces valeurs falseest un bon choix, car il empêche le traitement inutile et les requêtes de base de données s'il n'est pas nécessaire, et le cache est mis à jour de toute façon la première fois que des termes de champ / taxonomie personnalisés sont requis.

Cependant, si vous allez appeler, même une fois, get_post_meta()pendant la boucle et que vous allez appeler 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 pourrait n'y avoir aucun avantage réel sur définissant ces arguments de requête sur false.

Le principal point d'intérêt ici est la update_post_cachesfonction. Il est appelé après que WP_Query a obtenu tous les messages de la base de données. Habituellement, la raison pour laquelle vous souhaitez que les articles soient en premier lieu est de les afficher, ce qui signifie généralement afficher les termes et quelque chose en fonction des métadonnées.Par conséquent, WP_Query interrogera également par défaut la base de données pour les métadonnées et les données de terme liées aux articles renvoyés. 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 appellerez les API pertinentes pour obtenir le terme et les métadonnées d'une publication spécifique, elles seront déjà disponibles en mémoire et il ne sera pas nécessaire d'envoyer une nouvelle requête à la base de données.

Cela permet à wordpress de réduire les frais généraux liés à l'envoi de demandes à la base de données en envoyant une seule demande pour obtenir les informations pour tous les messages au lieu d'envoyer une demande pour chaque message.

Pour le moment, je ne trouve aucun exemple non trivial de quand ne voudrez-vous pas que le cache soit mis à jour, mais un exemple trivial pourrait être si vous voulez juste une liste des titres de tous les messages. Pour cela, vous n'avez pas besoin de termes 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 avoir de plugin de mise en cache d'objet actif. Évidemment, lorsque vous avez la mise en cache d'objets, les informations y seront également stockées.