Get_option () est-il plus rapide que d'accéder à get_transient ()?
Aujourd'hui, je teste ma base de données pour explorer la différence de vitesse entre l'accès à une clé à partir d'options, d'un tableau personnalisé et de transitoires. J'ai exécuté le test 1000 fois et voici le temps nécessaire pour exécuter 1000 opérations get:
get_transient()0.0245 secondesget_option()0.0068 secondes- opération de sélection simple à partir de la table personnalisée 0,65 secondes
J'ai également vérifié que le transitoire n'était pas expiré pendant ce test. La question est donc de savoir si get_option() est plus rapide que get_transient() ou est-ce que je me suis trompé dans mon test? Le délai dans la table personnalisée est-il dû au fait que WordPress a mis en cache les options par défaut? En outre, les options sont-elles également mises en cache par différents plug-ins de mise en cache, comme les transitoires?
Aujourd'hui, je teste ma base de données pour explorer la différence de vitesse entre l'accès à une clé à partir d'options, d'un tableau personnalisé et de transitoires. J'ai exécuté le test 1000 fois et voici le temps nécessaire pour exécuter 1000 opérations get:
N'oubliez pas que la table d'options est utilisée à la fois pour les options et les transitoires sur la plupart des systèmes. Cette table a été optimisée avec des index ajoutés. Donc ce n'est pas une comparaison juste
get_transient () 0.0245 secondes get_option () 0.0068 secondes, opération de sélection simple de la table personnalisée 0.65 secondes
C’est aussi une comparaison injuste, les options avec le jeu d’options de chargement automatique seront chargées plus tôt dans une requête unique. Donc, get_option extrait de WP_Cache, l'option a déjà été récupérée.
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 ait été récupéré
La question est donc de savoir si get_option () est plus rapide que get_transient () ou est-ce que j'ai gâché quelque chose dans mon test?
Ça dépend.
Le délai dans la table personnalisée est-il dû au fait que WordPress a mis en cache les options par défaut?
Très possible, mais la vitesse de sélection dépend beaucoup de la conception de la requête et de la table
En outre, les options sont-elles également mises en cache par différents plug-ins de mise en cache, comme les transitoires?
Oui, WP_Cache est utilisé, ce qui le stockera en mémoire pour le reste de la demande.
Répétabilité
Celles-ci sont toutes mises en cache via WP_Cache. Ainsi, la deuxième fois que vous le demandez, aucune base de données n'est impliquée.
La variabilité et ça dépend
Tout cela suppose une base commune, mais qu'en est-il des caches d'objets?
Introduisons une instance MemcacheD ou une instance Redis (je vous le recommande vivement si vous avez l'option, d'énormes avantages en termes de performances pour des sites bien construits, en particulier si vous les utilisez pour la mise en cache de pages, à moins que vous n'ayez quelque chose comme l'installation de Varnish)
Nous avons maintenant une nouvelle situation:
- À présent, les données sont 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 nettement plus rapide qu'une requête de base de données
- Un grand nombre de nouvelles données sont stockées dans
WP_Cache, ce qui n'est normalement pas le cas. Par exemple.WP_Postobjets, post meta, etc. WP_Cachepersiste désormais entre les demandes- MemcacheD etc. peut éliminer les transitoires expirés, etc.
Alors maintenant, les options transitoires et les options ont le même coût d’accès. Ils étaient déjà proches, mais ils sont maintenant négligeables et ont davantage à voir avec la charge de l'UC au moment où la demande a été faite.
Donc, pour la performance Devrais-je utiliser des transitoires ou des options?
Bien que la question mérite d'être posée, la réponse est que la différence est négligeable et entre des marges d'erreur.
Alors arrêtez la micro-optimisation, ils sont le même support de stockage, et ce n'est pas digne de votre temps
- Utilisez les options si vous devez stocker quelque chose qui concerne tout le site.
- Utilisez des éléments transitoires pour stocker temporairement les éléments coûteux à calculer pour ne pas avoir à passer à la prochaine
Votre temps ne vaut pas la peine de choisir l’un sur l’autre en fonction des performances, il n’ya pas de différence significative.
Il y a des choses bien meilleures à faire pour optimiser qui donnent des économies significativement plus grandes, par exemple. utiliser des taxonomies au lieu de méta dans les requêtes de publication, ne pas utiliser les paramètres de style __not, faire moins de choses sur la page, installer un cache d'objets, réduire le nombre de publications par page, éviter les requêtes distantes, etc.
Qu'en est-il d'une table personnalisée qui ...
Non, la table d'options est déjà bien optimisée. L'utilisation d'une table personnalisée déplace simplement les opérations en dehors du système de mise en cache WP, ce qui vous oblige à écrire vous-même.
Si aucune mise en cache d'objet n'est trouvée, get_transient appelle get_option deux fois, une fois ou l'intervalle d'expiration et un pour la valeur, par conséquent, la solution ne sera pas plus rapide.
get_option La performance en elle-même sera affectée si l'option est "autoloadée" (par défaut) ou non. Toutes les options à chargement automatique sont extraites dans une seule demande pour la base de données et stockées dans le cache de la mémoire. Par conséquent, le nombre d'appels de get_option au moyen de différentes options doit être très faible.
Lorsque vous accédez directement à la base de données, vous évitez toute mise en cache et toute autre amélioration des performances. Cette opération devrait être plus lente, à moins que vous n'implémentiez vous-même une logique intelligente.
Cela dit, je ne suis pas sûr que votre test soit bon, mais quoi qu'il en soit, toute la discussion est inutile, car si vous vous souciez vraiment des performances, vous utiliserez le système de cache d'objets (et le plug-in correspondant), ce qui rapprochera de beaucoup le temps d'accès aux données à zéro ... et bien sûr, si vous décidez d'utiliser vos propres tables de base de données, vous devez intégrer vos API d'accès au mécanisme de mise en cache des objets.