Tout le code WP n'est pas un code public
Si vous allez publier quelque chose de public, alors tout ce que kovshenin a dit est parfaitement valable.
Les choses sont différentes si vous allez écrire du code privé pour vous ou votre entreprise.
Le cache d'objets externes est un gros avantage, dans tous les cas
Pour définir un cache d'objets persistants externe est très recommandé , lorsque vous le pouvez.
Toutes les choses dites dans la réponse du kovshenin sur les transitoires et MySQL sont très vraies, et étant donné que WP lui-même et un tas de plugins utilisent le cache d'objets ... alors l'amélioration des performances que vous avez obtenue, vaut vraiment le (petit) effort de configuration un système de cache moderne comme Redis ou Memcached.
Les valeurs mises en cache peuvent ne pas être là: c'est bien
De plus, oui, un cache d'objets externe n'est pas fiable. Vous ne devriez jamais vous fier au fait qu'un transitoire est là. Vous devez vous assurer que cela fonctionne si la mise en cache n'est pas là où elle devrait être.
Le cache n'est pas un stockage, le cache est un cache.
Utiliser le cache de manière sélective
Voir cet exemple:
function my_get_some_value($key) {
// by default no cache when debug and if no external object_cache
$defUse = ! (defined('WP_DEBUG') && WP_DEBUG) && wp_using_ext_object_cache();
// make the usage of cache filterable
$useCache = apply_filters('my_use_cache', $defUse);
// return cached value if any
if ($useCache && ($cached = get_transient($key))) {
return $cached;
}
// no cached value, make sure your code works with no cache
$value = my_get_some_value_in_some_expensive_way();
// set cache, if allowed
$useCache and set_transient($key, $value, HOUR_IN_SECONDS);
return $value;
}
En utilisant un code comme celui-ci, dans votre site privé, les performances du site peuvent s'améliorer considérablement , surtout si vous avez beaucoup d'utilisateurs.
Notez que:
- Par défaut, le cache n'est pas utilisé lorsque le débogage est activé, donc, espérons-le, sur votre environnement de développement. Croyez-moi, le cache peut faire du débogage un enfer
- Par défaut, le cache n'est également pas utilisé lorsque WP n'est pas configuré pour utiliser un cache d'objets externe. Cela signifie que tout le problème lié à MySQL n'existe pas, car vous n'utilisez aucun transitoire lorsqu'ils utilisent MySQL. Une alternative probablement plus simple serait d'utiliser des
wp_cache_*fonctions , donc si aucun cache externe n'est configuré, le cache se produit en mémoire et la base de données n'est jamais impliquée.
- L'utilisation du cache est filtrable, pour gérer certains cas marginaux que vous pouvez rencontrer
Pas d'échelle Web si pas de cache
Vous ne devriez pas essayer de résoudre les problèmes de vitesse avec le cache. Si vous avez des problèmes de vitesse, vous devez repenser votre code.
Mais pour faire évoluer un site Web à l'échelle du Web, le cache est assez nécessaire .
Et souvent (mais pas toujours) fragmenté, le cache contextuel est beaucoup plus flexible et adapté que la mise en cache agressive pleine page.
Vos questions:
Dois-je utiliser l'API transitoire ici?
Ça dépend .
Votre code consomme-t-il beaucoup de ressources? Sinon, il n'y a peut-être pas besoin de cache. Comme je l'ai dit, ce n'est pas qu'une question de vitesse. Si votre code s'exécute rapidement mais qu'il nécessite un tas de CPU et de mémoire pour quelques utilisateurs ... que se passe-t-il lorsque vous avez 100 ou 1000 utilisateurs simultanés?
Si vous réalisez que le cache serait une bonne idée ..
... et est un code public: probablement non . Vous pouvez envisager de mettre en cache de manière sélective, comme dans mon exemple ci-dessus dans le code public, mais c'est généralement mieux si vous laissez ces décisions aux implémenteurs.
... et est un code privé: très probablement oui . Mais même pour le code privé, la mise en cache sélective est toujours une bonne chose, par exemple pour le débogage.
N'oubliez pas, de toute façon, que les wp_cache_*fonctions peuvent vous donner accès au cache sans risque de polluer la base de données.
Dois-je utiliser l'API transitoire pour mettre en cache le tableau $ related_posts ou la chaîne $ html_output?
Cela dépend de beaucoup de choses. Quelle est la taille de la chaîne? Quel cache externe utilisez-vous? Si vous allez mettre en cache des publications, le stockage de l'ID sous forme de tableau peut être une bonne idée, interroger un nombre décent de publications par leur ID est assez rapide.
Notes finales
L'API transitoire est probablement l'une des meilleures choses de WordPress. Grâce aux plugins que vous pouvez trouver pour tout type de systèmes de cache, cela devient une stupide API simple pour un grand nombre de logiciels qui peuvent fonctionner sous le capot.
En dehors de WordPress, une telle abstraction qui fonctionne tout de suite avec un tas de systèmes de mise en cache différents et vous permet de passer d'un système à un autre sans effort est très difficile à trouver.
Vous pouvez rarement m'entendre dire que WordPress est meilleur que d'autres choses modernes, mais l'API transitoire est l'une des rares choses qui me manquent lorsque je ne travaille pas avec WordPress.
Le cache est sûrement difficile, ne résout pas les problèmes de code et n'est pas une solution miracle, mais c'est quelque chose dont vous avez besoin pour créer un site à fort trafic qui fonctionne.
L'idée WordPress d'utiliser une table MySQL sous-optimisée pour faire du cache est assez folle, mais il n'est pas préférable de vous tenir à l'écart du cache simplement parce que WordPress, par défaut, le fait.
Il vous suffit de comprendre comment les choses fonctionnent, puis de faire votre choix.