Aujourd'hui, je lance un test sur ma base de données pour explorer la différence de vitesse entre l'accès à une clé à partir d'options, d'une table personnalisée et de transitoires. J'ai exécuté le test 1000 fois et voici le temps nécessaire pour exécuter 1000 opérations get:
Gardez à l'esprit que la table d'options est utilisée à la fois pour les options et les transitoires sur la plupart des systèmes, et cette table a été optimisée, avec des index ajoutés. Ce n'est donc pas une comparaison juste
get_transient () 0,0245 secondes get_option () 0,0068 secondes opération de sélection simple à partir du tableau personnalisé 0,65 secondes
C'est également une comparaison injuste, les options avec le autoloadjeu d'options seront chargées en avance dans une seule requête dès le début. Il en get_optionva de même pour WP_Cachel'option, l'option a déjà été récupérée.
TLDR: Il ne récupère pas réellement l'option, il a déjà été récupéré, il est juste en train de le retirer de la mémoire en raison de l' autoloadoption
J'ai également vérifié que le transitoire n'était pas expiré pendant ce test.
Cela ne devrait pas avoir d'impact sur un système normal sur la récupération transitoire, après tout, il ne sait pas s'il a expiré jusqu'à ce qu'il soit récupéré.
La question est donc de savoir si get_option () est plus rapide que get_transient () ou ai-je gâché quelque chose dans mon test?
Ça dépend:
- Sur la plupart des systèmes, les transitoires sont stockés à l'aide d'options, les deux impliquent un
get_optionappel
- Les options dont la valeur est
autoloaddéfinie sur true sont toutes chargées en un seul appel au début, elles sont donc conservées en mémoire, aucune requête ne se produit après cela.
- La mise en cache d'objets met en cache à la fois les options chargées automatiquement et les transitoires
Le délai de table personnalisé est-il dû aux options mises en cache par défaut par WordPress?
Très possible, mais la rapidité de cette sélection dépend beaucoup de la conception de la requête et de la table
De plus, les options sont-elles également mises en cache par différents plugins de mise en cache comme les transitoires?
Oui, WP_Cacheest utilisé, qui le stockera en mémoire pour le reste de la demande. La mise en cache des plugins peut conserver ces valeurs pour des raisons de performances.
Répétabilité
Ceux-ci sont tous mis en cache via WP_Cachedonc la deuxième fois que vous le demandez, aucune base de données n'est impliquée.
Variabilité et cela dépend
Tout cela suppose une base commune, mais qu'en est-il des caches d'objets?
Permet d'introduire une instance MemcacheD ou une instance Redis (je vous recommande fortement de le faire si vous avez l'option, d'énormes avantages en termes de performances pour les sites bien construits, surtout si vous les utilisez pour la mise en cache des pages, sauf si vous avez quelque chose comme la configuration de Varnish)
Maintenant, nous avons une nouvelle situation:
- Les données sont désormais stockées dans la RAM et une fois extraites de la base de données, elles sont amorcées et les temps d'accès sont considérablement réduits. Toujours plus lent qu'une variable, mais beaucoup plus rapide qu'une requête de base de données
- Beaucoup de nouvelles données sont stockées dans
WP_Cachece qui n'est normalement pas le cas. Par exemple, WP_Postobjets, post méta, etc.
WP_Cache persiste désormais à travers les demandes- MemcacheD, etc. peut éliminer les transitoires expirés, etc.
Alors maintenant, les transitoires et les options ont le même coût d'accès. Ils étaient déjà proches, mais ils sont désormais négligeables et ont davantage à voir avec la charge du processeur au moment de la demande.
Donc, pour des performances dois-je utiliser des transitoires ou des options?
Bien qu'il soit utile de se poser la question, la réponse est que la différence est négligeable et dans les marges d'erreur
Alors arrêtez la micro-optimisation, c'est le même support de stockage, et ce n'est pas digne de votre temps
- Utilisez des options si vous avez besoin de stocker quelque chose à l'échelle du site
- Utilisez des transitoires pour stocker temporairement des éléments coûteux à calculer afin de ne pas avoir à la prochaine fois
Cela ne vaut pas la peine de choisir l'un plutôt que l'autre en fonction des performances, il n'y a pas de différence significative.
Il y a de bien meilleures choses à faire pour optimiser ce qui permet de réaliser des économies significativement plus importantes, par exemple en utilisant des taxonomies au lieu de méta dans les requêtes de publication, en n'utilisant pas les __notparamètres de style, en faisant moins de choses sur la page, en installant un cache d'objets, en réduisant les publications par page, en évitant les requêtes distantes etc
Qu'en est-il d'une table personnalisée qui ...
Non, le tableau d'options est déjà bien optimisé, l'utilisation d'un tableau personnalisé déplacera simplement les opérations en dehors du système WP Caching, vous forçant à écrire le vôtre