Comprendre la mise en cache dans WordPress, partie 3
Dans les deux articles précédents, j’ai parlé des bases de la mise en cache et du fonctionnement de la mise en cache dans WordPress, au moins dans une certaine mesure.
Mais rappelez-vous que cette série a été motivée par un e-mail de quelqu’un qui pensait que je pouvais mieux expliquer comment les transitoires et la mise en cache fonctionnent dans WordPress et pourquoi il est important de comprendre comment tout fonctionne en tandem.
Donc, dans cet article, je vise à tout rassembler et à expliquer comment l’ API Transients fonctionne en conjonction avec MySQL, pourquoi il est important de comprendre la relation et comment gérer cela pour aller de l’avant.
Comment fonctionnent les transitoires dans WordPress ?
Comment fonctionnent les transitoires
Tout d’abord, selon le Codex, les transitoires fonctionnent comme ceci :
Cette page contient la documentation technique de WordPress Transients API, qui offre un moyen simple et standardisé de stocker temporairement les données mises en cache dans la base de données en leur donnant un nom personnalisé et un délai après lequel elles expireront et seront supprimées.
L’idée derrière cela semble assez simple, non?
- Vous enregistrez une option dans la base de données,
- Définissez une heure pour combien de temps il devrait exister,
- Ensuite, il est stocké pendant ce laps de temps
- Et, si demandé après expiration, est récupéré et remis dans son état transitoire.
Alors où est la confusion ?
Comme mentionné dans le premier message, je n’étais pas clair sur la durée pendant laquelle les informations transitoires seraient disponibles. Plutôt que d’être un minimum de temps pendant lequel les données seront disponibles, c’est un maximum.
Cela signifie que si vous définissez quelque chose pour qu’il soit disponible pendant une journée, il sera disponible pendant une journée. Pas moins; Pas plus. Et une fois ce délai expiré, il devra être recréé dans l’état transitoire une fois de plus.
Au moins, c’est la sagesse conventionnelle derrière cela. Ce n’est pas faux mais il y a plus que ça. C’est là que ça devient un peu plus technique, cependant.
Quel rôle joue MySQL ?
Au fur et à mesure que WordPress, l’hébergement et d’autres technologies ont mûri, les bases de données sous-jacentes qui alimentent l’application ont également changé. Ce n’est ni une bonne ni une mauvaise chose (même si nous pourrions peut-être dire que c’est une bonne chose dans un prochain article).
Mais cela peut aider à expliquer pourquoi les transitoires fonctionnent comme ils le font compte tenu de la pile avec laquelle nous avons l’habitude de travailler et comment ils peuvent ne pas fonctionner comme prévu sans les systèmes de base de données.
Si vous choisissez d’utiliser MySQL comme base de données pour votre installation WordPress, ce que j’ose dire que la plupart des gens font encore, alors les informations qui se trouvent dans la table Options (où les transitoires sont également stockés), alors l’API Transients fonctionnera comme décrit ci-dessus.
Mais que se passe-t-il lorsque vous introduisez d’autres formes de mise en cache comme la mise en cache d’objets via des logiciels comme Memcached ou Redis, etc. ?
Dans ce cas, les données peuvent ne pas être disponibles comme prévu. En bref, le logiciel de mise en cache peut choisir de supprimer les informations qui ne sont pas demandées aussi souvent que les autres informations. C’est-à-dire qu’il donne un niveau de priorité aux informations les plus fréquemment demandées.
Avancer
Lorsque vous tenez compte de tout ce qui précède, vous examinez plusieurs choses :
- l’API Transitoires,
- une base de données,
- un système de cache tiers.
Lorsque vous avez l’API Transients et une base de données standard, tout ira bien dans la mesure où les choses fonctionneront comme prévu.
Mais si vous introduisez un système de mise en cache tiers, le résultat peut être différent. Plus précisément, les choses peuvent ne pas fonctionner – et ne fonctionneront probablement pas – comme prévu.
Autrement dit, le système de mise en cache tiers peut ignorer les informations qu’il souhaite supprimer chaque fois qu’il pense devoir les supprimer. Cela signifie que tout ce que vous pensez avoir disponible dans le cache n’y sera pas.
En fin de compte, le meilleur conseil que je puisse donner est celui-ci :
- Si vous utilisez MySQL et l’API Transients, les choses fonctionneront comme décrit dans le Codex.
- Si, d’autre part, vous utilisez un autre système de mise en cache, il est important de comprendre comment il fonctionne et comment vous pouvez écrire du code dessus pour qu’il fonctionne comme vous le souhaitez.
Et avec cela, il n’y a rien de plus à ajouter à cette introduction pour comprendre la mise en cache dans WordPress.