Je defend l’interet d’un tel critere en precisant mon cas. J’ai cree une page type, qui comporte une boucle qui est utilisee jusqu’a plusieurs centaines de fois par page. A chaque passage dans cette boucle la requete generee est unique de par ses parametres, pour la page et meme pour le reste du site c’est une certitude. Cette page se decline en plusieurs centaines de versions. Au final, c’est un potentiel de plusieurs centaines de milliers de requetes uniques que je viens d’ajouter dans mon site, et puisque le cache SPIP fait son travail, je sais d’autant plus que plusieurs jours au minimum vont s’ecouler avant que les memes requetes ne reapparaissent dans le serveur SQL.
Le cache SQL n’a d’interet que si on pense avoir une chance de retrouver et reutiliser les requetes, ce qui n’est pas le cas ici. Encore une fois cela touche un squelette en particulier donc desactiver le cache de maniere globale ne m’aidera pas il est sans doute utile pour le reste du site. Donc je vois clairement deux raisons pour utiliser un tel critere dans mon cas:
-
C’est plus rapide d’effectuer une requete purement et simplement, plutot que d’interroger le cache sans succes, effectuer la requete, puis la mettre en cache (inutilement).
-
Le cache SQL a une limite en taille, en mettant mes centaines de milliers de requetes en cache pour rien je prive le systeme de mettre en cache des requetes qui ont une chance d’en beneficier.
Ce qui m’a alerte, c’est qu’apres avoir mis en place mon squelette, et apres l’avoir teste sans aucun soucis, le load server est monte tres haut quelques heures plus tard, ce qui correspond vraissemblablement a une visite d’un moteur de recherche. Plusieurs heures durant, le load mysql restait eleve, bien que la vague soit passee. En jetant un oeil aux process SQL, je reconnaissais les requetes de ma boucle, qui continuaient a defiler, avec comme statut « statistics » ou « writting to net ». Si cette activite a retardement est bien liee au cache comme je le soupconne, dans ce cas il faut que je le bypass. Bien sur, maintenant que la plupart de ces pages ont ete mises en cache SPIP, le rafraichissement va s’etaler a l’avenir et je ne devrais plus avoir ce pic brutal de load SQL. Mais j’aimerai etre a l’abris car il est possible que j’aie a purger le cache un jour, ou bien changer des parametres dans mes templates qui invalideraient les noms de mes caches actuels. Et puis ca ne mange pas de pain de gagner quelques microsecondes de maniere constante en ce qui concerne ces boucles.
Dites moi si je me trompe quelque part.
Benoit Aubert
From: cedric@yterium.com
Date: Mon, 20 Jan 2014 19:17:45 +0100
To: jluc@no-log.org
CC: spip-zone@rezo.net
Subject: Re: [SPIP Zone] critere SQL_NO_CACHE
Le 20 janv. 2014 à 12:44, JLuc <jluc@no-log.org> a écrit :
Et globalement, dans quels cas serait il recommandé de peut être utilisé ce critère ?
Très clairement : la recommandation est de ne jamais l’utiliser.
Ce ne peut avoir une utilité que dans des cas très précis qui suppose que l’admin système est capable de dire que telle ou telle requête pose un problème à cause de la gestion de cache MYSQL, ce qui est le cas d’espèce ici. Mais même comme ça, cela suppose de vérifier de manière régulière de l’intérêt de ce compromis, car rien ne prouve qu’il soit définitif.
---- spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone