Explication de update_post_ (meta / term) _cache

20

Je lisais certaines meilleures pratiques de 10up et ils mentionnent la définition de false pour ces deux drapeaux dans un 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 supposé utiliser quelque chose comme update_post_caches() , mais je ne suis même pas 100% sûr de ce que cela signifie. Quelqu'un pourrait-il expliquer la signification de ces deux drapeaux 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 en cache les choses, mais une réponse bien pensée concernant ces deux drapeaux est également acceptable.

    
posée Howdy_McGee 27.01.2016 - 18:29

2 réponses

26

Cache d'objet 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 taxonomie, avant d'interroger la base de données, WordPress vérifie s'il 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 de cache" est effectué via les WP_Object_Cache class et wp_cache_* functions (qui sont enveloppés dans cette page). méthodes de classe.)

Où vit le cache

Par défaut, le "cache" n'est rien de plus qu'une variable globale PHP. Cela signifie qu’elle est en mémoire, mais aussi qu’elle disparaît à chaque requête.

Cependant, via les dropins ( advanced-cache.php et / ou object-cache.php ), il est possible de configurer une méthode personnalisée pour gérer ce cache.

Habituellement, ces dropins sont utilisés pour configurer un mécanisme de mise en cache qui "survit" aux requêtes singulières.

Pour cette raison, ces personnes sont connues sous le nom de plug-ins "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 à l'heure actuelle sont Memcached ou Redis .

Ainsi, en utilisant les 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 deux lignes de code ci-dessus vont déclencher, au maximum, une requête 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 des données du cache et non de la base de données.

Même chose 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 articles, les méta-valeurs et les taxonomies, mais également pour les utilisateurs, les commentaires, les données de thème ...

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

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 en rapport avec les posts extraits.

Ainsi, lorsque vous appelez, par exemple, get_the_terms() ou get_post_meta() alors que les posts en boucle reçus via WP_Query , vous ne déclenchez aucune requête de base de données, mais extrayez des informations du 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 messages via WP_Query se produit dans update_meta_cache pour les méta et dans update_object_term_cache pour les 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 existe 7% imbriqués foreach ... 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_Query arguments, enfin

Ce que 'update_post_meta_cache' et 'update_post_term_cache' font lorsqu'ils sont définis sur false est 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 la peine?

Comme d'habitude, la réponse est cela dépend . La plupart du temps, le fait de définir ces valeurs sur false 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 / champ personnalisés.

Cependant, si vous appelez, même une fois, get_post_meta() au cours de la boucle et appelez get_the_terms() pour toutes les taxonomies (ou la plupart) prises en charge par les publications, la mise à jour du cache est quand même déclenchée. , et il pourrait ne pas y avoir d’avantage réel à définir ces arguments de requête sur false .

    
réponse donnée gmazzap 27.01.2016 - 20:20
3

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 la base de données pour les métadonnées et les données de terme associées aux publications renvoyées. et stocke 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 requêtes à la base de données en n’envoyant qu’une requête pour obtenir les informations relatives à toutes les publications au lieu d’envoyer une requête pour chaque publication.

Pour le moment, je ne trouve aucun exemple non trivial de la date à laquelle vous ne souhaitez pas que le cache soit mis à jour, mais un exemple peut être trivial si vous souhaitez simplement obtenir une liste des titres de tous les messages. 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.

    
réponse donnée Mark Kaplun 27.01.2016 - 19:23

Lire d'autres questions sur les étiquettes