Mise en cache d'objets WordPress : API Redis, Memcached et natives

Les sites WordPress de niveau entreprise qui peuvent évoluer à volonté ont besoin d'un mécanisme de mise en cache persistant au-delà des pages et des images, un mécanisme qui peut mettre en cache les objets PHP réels. Bien que WordPress fournisse un mécanisme de mise en cache d'objets via le cache d'objets WordPress, il existe d'autres solutions qui offrent un effet de levier et une puissance considérables. Mais avant d'aborder tout cela, nous devons d'abord voir ce qu'est la mise en cache d'objets et comment cela fonctionne en PHP.

Qu'est-ce que la mise en cache d'objets ?

PHP est un langage orienté objet. Il utilise le paradigme de l'objet pour structurer le code. En conséquence, votre site WordPress se compose de nombreux objets PHP différents qui sont constamment créés, instanciés et détruits (par le gestionnaire de mémoire). La création et la destruction d'objets ont un surcoût, en particulier s'ils sont nombreux. Cependant, la plupart d'entre eux ont tendance à être beaucoup réutilisés car ils représentent des fonctionnalités de base. Cela signifie qu'à chaque fois que l'application en aura de nouveau besoin, elle devra les instancier depuis le début.

Et si vous pouviez mettre en cache un objet instancié fréquemment utilisé afin de ne pas avoir à le détruire et à le créer tout le temps ?

Vous pouvez utiliser la fonction PHP serialise() pour convertir un objet ou une primitive en une représentation numérique (blob d'octets) qui peut être stockée en mémoire ou sur le disque pour un accès ultérieur. Ensuite, vous calculez le numéro de hachage du blob d'octets à l'aide de la hash() et stockez les deux. Le hachage comme clé et le blob d'octets comme valeur. Pour le récupérer, vous utilisez le numéro de hachage calculé du blob d'octets qui a été initialement stocké sous forme de clé. Vous pouvez transformer n'importe quoi (chaîne, entier, objet, booléen, tableau, etc.) en une représentation stockable d'une valeur de cette façon.

Exemple:

$serialized = serialize( array ( 'test' ));

Effectuez l'opération inverse, avec unserialize() :

$original = unserialize ( $serialized );

En général, il existe trois façons de mettre en cache des objets : en utilisant le cache d'objets WordPress natif, l'API Transients ou un magasin clé-valeur externe comme Redis ou Memcached.

Mise en cache des objets WordPress

WordPress propose deux API de mise en cache d'objets : le cache d'objets WordPress natif et l'API Transients. Ils sont identiques, et bien que cela puisse prêter à confusion, il y a une logique derrière cela.

Le cache d'objets WordPress natif peut stocker des objets et des primitives dans le cache, mais pas de manière persistante par défaut. Cela signifie que la mise en cache se produit en mémoire et que les objets mis en cache ne vivent pas au-delà du cycle de vie de la requête. Vous ne pouvez donc pas partager vos objets mis en cache sur différents chargements de page. Vous devez fournir votre propre implémentation de magasin avec l'utilisation de Drop-Ins, qui sont des plugins "avancés" qui peuvent étendre les fonctionnalités de WordPress. Vous pouvez les voir sur votre tableau de bord WordPress, dans la liste des plugins :

L'API Transients, quant à elle, est prête à l'emploi. Vous pouvez enregistrer des variables, des tableaux, des objets liés avec une date d'expiration directement sur une base de données et avoir une mise en cache d'objets persistante. Cependant, le problème est que lorsque vos objets mis en cache expirent, ils restent sur la base de données en prenant de l'espace. Cela signifie qu'il y a une surcharge supplémentaire consacrée à la maintenance de la base de données, en éliminant de temps en temps les objets expirés.

WordPress détecte si vous avez implémenté votre propre cache d'objets persistants et lorsqu'il constate que c'est le cas, les appels à l'API Transients sont contournés et acheminés vers le cache d'objets WordPress (et donc la raison pour laquelle ils sont identiques).

Les développeurs peuvent implémenter leur propre cache d'objets, utiliser un plugin WordPress (plus d'informations sur ceux-ci plus tard) ou notre propre implémentation, s'il s'agit d'un client Pressidium. Le cache d'objets n'est pas activé par défaut, car cela peut entraîner des baisses de performances s'il est utilisé dans la mauvaise situation. Il n'existe pas de solution « taille unique » en matière de mise en cache d'objets dans les sites WordPress.

Redis et Memcached

Les magasins clé-valeur n'utilisent pas de tables et de types de données prédéfinis pour stocker des informations dans des enregistrements tels que dans RDBMS. Ils sont conçus pour stocker et récupérer des paires clé/valeur, comme dans les structures de données de dictionnaire que vous trouvez dans les langages de programmation.

Un bel exemple d'un tel magasin est Redis. Outre les structures de données de dictionnaire, il en prend en charge une pléthore d'autres, y compris des structures avancées telles que des ensembles triés avec des requêtes de plage et des index géospatiaux avec des requêtes de rayon. Il offre une mise en cache persistante des objets .

Redis n'est pas seulement un magasin ou un cache clé-valeur. Il prend en charge la réplication des données, les scripts et la haute disponibilité dans une configuration en cluster. Vous pouvez également affiner le niveau de persistance sur disque souhaité. La bonne chose à propos de Redis est que si vous redémarrez, la majeure partie de votre cache sera toujours sur disque, les données perdues ne seront qu'une petite fraction. Le fait est qu'au redémarrage, le serveur devrait reconstruire le cache et cela augmente la plupart du temps la charge. Avec Redis, cela ne se produit pas. De plus, les objets arrivés à expiration sont immédiatement supprimés de la base de données. Pas de frais généraux de gestion là aussi.

Redis Labs a une excellente page présentant les cas d'utilisation de Redis dans l'entreprise : ceux-ci vont des ensembles de données très volumineux à la recherche en texte intégral, aux séries en temps réel, à l'intégration Spark, etc.

Bien que toutes ces fonctionnalités coûtent en complexité et peut-être en vitesse dans certains cas, l'optimisation de votre code Redis Drop-In peut apporter de nombreux gains. N'oubliez pas le fait que Redis fait de la mise en cache persistante des objets , ce que Memcached ne fait pas, bien qu'il soit beaucoup plus simple à utiliser.

Memcached est un système de mise en cache d'objets hautes performances en mémoire qui, selon le site Web officiel, est spécialement conçu pour accélérer les applications Web dynamiques et alléger la charge de la base de données. Il est également beaucoup plus simple et direct à utiliser que Redis.

En raison de sa conception spécifique pour la mise en cache d'objets pour les pages Web et du fait qu'il utilise une base de données en mémoire, il s'agit de la solution de mise en cache d'objets la plus rapide du marché. Cependant, comme nous l'avons mentionné précédemment, si votre serveur redémarre, votre cache est épuisé. Et jusqu'à ce qu'il soit reconstruit, vous subirez probablement une charge accrue. Mais comme le disent les créateurs : "considérez-le comme une mémoire à court terme pour votre site Web", cela dépend donc plutôt de ce que vous voulez faire en premier lieu.

Étant donné que Memcached utilise une base de données en mémoire pour conserver le cache, il est très efficace pour mettre en cache les requêtes SQL, les sorties d'appel de fonction, etc.

Plugins WordPress

• WP Redis, le plugin Redis WordPress officiel. Prend en charge WP-CLI, le clustering et la réplication.
• Redis Object Cache Un autre plugin Redis back-end pour WordPress.
• Memcached Object Cache, le backend pour Memcached.
• Supprimer les transitoires expirés, ce plugin supprime les objets transitoires expirés de la base de données. Il prend également en charge le multisites !

Comment exécuter des benchmarks

Le but de notre article est de vous enthousiasmer pour la mise en cache d'objets et de commencer à bricoler par vous-même. Vous pouvez essayer diverses implémentations de cache persistant et voir le comportement de votre application. Vous pouvez utiliser la fonction PHP microsecond() pour comparer les appels. Par exemple : appelez microsecond() avant et après avoir appelé wp_cache_get() , soustrayez les valeurs et stockez le résultat. Faites cela pour différentes implémentations de cache et voyez dans quels cas vous remarquez un gain de performances.

Chez Pressidium, nous n'avons pas la mise en cache d'objets activée par défaut et bien que ce soit quelque chose qui peut être demandé, nous ne le conseillons généralement pas dès le départ. Nous effectuons des tests et nous nous assurons que votre site va en tirer profit.

Conclusion

Disons que pour afficher une page, l'application doit lire 2 000 objets transitoires. Cela signifie 2 000 lectures sur la base de données. En utilisant un système de mise en cache d'objets persistants, ces 2 000 lectures sont déchargées vers le magasin clé-valeur. Si vous utilisez memcached, vous risquez de perdre tout votre cache lors d'un redémarrage soudain. En général, Redis n'est peut-être pas aussi rapide que Memcached, mais ses fonctionnalités d'entreprise et sa persistance vous profitent à long terme.

Cependant, une taille ne convient pas à tous ! Par exemple, nous avons vu des instances Redis qui ralentissaient les sites Web et, dans d'autres cas, les accéléraient incroyablement. Cela a à voir avec un certain nombre d'objets que votre application utilise : en général, si votre application en utilise quelques-uns (disons une douzaine), vous ne bénéficierez pas beaucoup de la mise en cache des objets, et dans le pire des cas, vous avoir une surcharge de réseau. Si toutefois, votre application se compte par centaines, il pourrait être avantageux d'y jeter un coup d'œil.