Bonjour, étant en train de réfléchir à comment diminuer les « accès base de donnée » Spip, je me suis dit qu’une façon facile serait d’augmenter la durée par défaut de mise en cache des pages calculées. En consultant la documentation je vois que la valeur par défaut est de 24h mais que ça peut se modifier dans chaque squelette en mettant la directive #CACHE en tête de page. Mais est-ce qu’il est possible de modifier la valeur par défaut quelque part dans l’admin ?
La doc indique #CACHE - SPIP :
[…] par défaut, la durée est de 24 heures (définie par la constante
_DUREE_CACHE_DEFAUT).
J’y ai pensé aussi mais, si je comprends bien, augmenter la durée du cache à 7j au lieu de 24h par ex ne permet de gagner que 6 recalculs par semaine, quelque soit le nombre de visites, c’est pas vraiment là que ça se joue.
1 « J'aime »
Il faudrait aussi trouver une solution pour ne se connecter à la base que lorsque c’est nécessaire : chaque hit http crée une connexion à la base. Vaste chantier, certes, mais si SPIP fournit des caches à plusieurs niveaux, notamment pour afficher des pages quasi statiques, ce serait bien de ne pas créer une connexion à la base systématiquement …
Ensuite, certains squelettes produisent des requêtes SQL bien lourdes. Certaines boucles pourraient être optimisées, j’imagine. Plus certains squelette.html avec un #CACHE{0} systématique.
Enfin, les tâches de fond (cron/genie/…) exécutées suite à un hit HTTP, sur les sites à gros trafic, il faudrait aussi les externaliser pour être traitées par un worker php indépendant. Vaste chantier là aussi, mais ça ferait du bien, je pense.
C’est pour quel besoin ?
Il me semble qu’historiquement, SPIP a été conçu comme ça. Et cela n’a sans doute pas été questionné par la suite : il est difficile de prévoir les besoins en données stockées en base :
Les métas et les config, tout script ajax, toute action spip nécessitant une authentification, l’espace privé qui rafraichit certaines données par principe, toutes les tâches de fond s’appuyant sur la job queue qui ne fonctionne qu’avec SQL, les plugins stockés par SVP depuis le ou les dépôts, le fait que toute requête POST soit autorisée sur toutes les pages et qu’un POST désactive le cache … et j’en passe.
C’est pas un défaut de conception, c’est juste plus simple, ça permet de ne pas y penser. Certain·e·s mettent un reverse-proxy qui fait du cache http, il y a le mysql.out qui peut s’activer, il y a eu plein d’inventions pour contourner le problème que cela peut poser, mais la connexion systématique est toujours là.
1 « J'aime »
Ya des petites améliorations à portée de main sûrement.
Par exemple j’ai récemment constaté, sur des tables moyennement dimensionnées, que les TIMESTAMPDIFF MYSQL étaient 200 fois plus coûteux que les comparaisons de date et que je pouvais gagner « beaucoup » de temps en remplaçant le critère age qui y a recours par la simple comparaison avec une date précalculée par PHP via un filtre SPIP.
Peut être le critère age pourrait il détecter les situations où il peut se passer de TIMESTAMPDIFF ?
Cf
- public/criteres.php · 5.x · spip / ecrire · GitLab pour
calculer_param_date - public/criteres.php · 5.x · spip / ecrire · GitLab pour
calculer_critere_infixe_date
Ya aussi la constante _AGE_CACHE_ATIME, qui définit l’âge maximal d’un cache non utilisé. Elle permet, notamment, le ménage anticipé des fichiers de cache inutilement générés par le passage d’un robot indexeur, qui rend visite de manière indifférenciée à des pages qui ne sont par ailleurs visitées que très rarement.
En fait j’ai l’impression que ce qui fait couiner les hébergeurs mutualisés qui se plaignent tout à coup d’une « activité élevée » sur nos sites, c’est quand il y a un robot (IA ou autre) qui vient d’un seul coup aspirer toutes les pages, ce qui « réveille » des vieilles pages où la mise en cache a expiré. Dans le cas du post bdd bloquée chez Ionos - Général - Discuter de SPIP le site a ~6000 articles, et si les 6000 pages en cache ont expiré au bout de 24h le robot va faire générer à Spip 6000 * X requêtes SQL pour les recalculer (suivi de l’écriture de 6000 nouveaux fichiers cache).
Après je pense que mon approche de juste dire « est-ce qu’on peut régler une durée de cache plus longue » est un peu naïve, dans le sens où le cache finira toujours par expirer et, d’après Murphy, ce sera toujours juste avant qu’un robot passe.
En fait, un truc qui pourrait être cool, ce serait que si Spip détecte que le « visiteur » est un robot, de lui servir les pages en cache même si celles-ci ont expiré - tout au moins en ce qui concerne les pages qui ne sont pas toutes récentes. Après tout le robot n’a pas nécessairement besoin d’une version rafraîchie de toutes les archives du site…
1 « J'aime »
C’est vrai, je n’avais pas pensé à ce cas de figure.
Peut-être regarder du côté de Cache Cool - SPIP-Contrib qui diffère le recalcul des pages ? Mais s’il n’étale pas ce recalcul, sans doute que ça ne fait que différer le problème justement.
Intéressant, je ne connaissais pas !
Sinon j’ai vu ça qui répond à ma question de départ : Configurer le cache - Programmer avec SPIP 4
où doit-on coder cette valeur ? Dans mes_options.php ?
yep
1 « J'aime »
C’était déjà la réponse apportée par @jeanmarie plus haut cf Configurer la durée de mise en cache - #2 par jeanmarie 
2 « J'aime »
Le 28/10/2025 à 09:39, maathieu via Discuter de SPIP a écrit :
En fait, un truc qui pourrait être cool, ce serait que si Spip détecte que le « visiteur » est un robot, de lui servir les pages en cache même si celles-ci ont expiré - tout au moins en ce qui concerne les pages qui ne sont pas toutes récentes. Après tout le robot n’a pas nécessairement besoin d’une version rafraîchie de toutes les archives du site…
Bah c’est déjà le cas depuis des années non ? Il y a déjà une détection de robot, et on ne sert déjà pas la même chose aux robots qu’aux vrais visiteurs.
Mais la détection de robot c’est pas infaillible et ça change tout le temps avec les nouveaux bots IA en plus des bots classiques des moteurs de recherche.
–
RastaPopoulos
1 « J'aime »
SPIP fait alors l’économie du recalcul d’une page dans le cas où un cache existe déjà, même s’il est périmé. Mais s’il n’existe pas de cache (par exemple parce que c’est une page que des internautes humains ne consultent qu’une fois tous les 36 du mois), alors il n’y a pas d’échapatoire et le HTML doit être calculé.
1 « J'aime »
Ah trop bien, je savais pas que ça avait été implémenté ! J’en apprends chaque jour davantage sur Spip :-). Du coup le problème vient sans doute des bots qui se font passer pour des visiteurs ordinaires…
Ça peut donner envie de créer une détection dynamique des bots :
- mettre un piège à bot (un lien caché, que les humains ne cliqueront pas)
- enregistrer une signature du bot tombé dans le piège (son IP, son UA…)
- reconnaître le bot lors d’une prochaine visite
- lui appliquer le traitement mérité
Le développement de nouvelles armes offensives entraîne le développement de nouvelles armes défensives, dans une course sans fin qui bouffe le temps des devs et l’habitabilité de la planète…
Pas con du tout ça.
Je me le note dans les idées de projets pour quand j’ai cinq minutes.
Oups j’ai écrasé ce message et le lien initialement contenu en voulant poster un autre message. C’était un article en anglais qui parlait de différentes techniques de piègeage et blocage des robots, avec de nombreux liens vers des outils. Il y était question de poisoning aussi.
J’ai pas retrouvé ce lien mais en voici quelques un en rapport avec le sujet :
2 « J'aime »
Bonjour à tous,
Utilisateur depuis une vingtaine d’années de Spip, j’ai donc vécu quasiment toutes les version du CMS. J’ai tout de même l’impression que le cache dans les anciennes versions, peut-être même la 2 était beaucoup plus puissant qu’aujourd’hui. Du moins, il faisait ce qu’il devait faire.
Je me me souviens qu’il m’arrivait d’avoir des soucis de base de données et le site était quand même fonctionnel car la page servie était en cache. Aujourd’hui dès qu’il y a un souci de Mysql, nous avons le fameux message « un souci mysql … », alors même qu’un cache est mis à 60 minutes en page d’accueil.
En soit, rien d’important, j’ai d’autres outils pour pallier ce manque.
Said
SPIP met en cache certains éléments de la base de données pour éviter des appels intempestifs au serveur SQL et pour que l’affichage des pages publiques déjà en cache puisse fonctionner même si le serveur de base de donnée est indisponible. (source: Cache SQL - Programmer avec SPIP 4)
1 « J'aime »