Il faudrait préciser sur la base de quoi tu t’exprimes.
Il y a 20 ans, le web était fréquenté en grande majorité par des humains, dont les intérêts étaient humains. Le cache était donc très efficace pour les articles appréciés des humains. Les articles jamais consultés… n’étaient jamais consultés et leur absence en cache ne posait problème à personne.
Aujourd’hui, 60 à 80% des visites viennent de robots et ceux ci ont très mauvais goût. Pire encore : ils ont pas de goût du tout : ils lisent tout sans choisir et sans préférence. Ce faisant ils saturent le cache et le rendent en partie inopérant.
Mais le cache marche bien a priori : ballade toi sur 2 ou 3 pages lambda de ton site. Puis, via FTP (et sans aller dans /ecrire ni recalculer de pages avec ?var_mode), retire dans config/connect.php le mot de passe qui permet la connexion à la BDD. Retourne sur les pages précédemment visitées : sont elles lisibles ? Remet le mot de passe ensuite
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 :
A priori non, historiquement SPIP devrait servir les hits en cache sans se connecter à la base : le cache principal est cherché à partir de l’URL, sans requete en base, et si on le trouve on déroule les inclusions.
La multiplicité des inclusions avec env + l’utilisation de formulaires dynamiques peut rendre ça plus compliqué, surtout si on intègre les-dit formulaires dans les en-tete ou pied de page
Mais la problématique soulevée par les hébergeurs est plutôt lié au surcroit de traffic de bots (et en particulier les bots aspirant tout pour nourrir les modèles d’IA) qui parcourent inlassablement toutes les URLs possibles et donc pas dans le cache.
Sans compter les cas assez fréquent de boucles infinies d’URL générées par des squelettes pas toujours au top sur ce point (ie un lien basé sur #SELF dans lequel on ajoute un argument sans trop de précaution, et à chaque affichage ça rallonge l’URL proposée)
On a vu passer ça sur Seenthis, et je l’ai encore vu sur un autre site submergé par les appels de bots: des bots programmés de manière merdique qui ne comprennent pas <base href=''> et qui du coup fabriquent des milliers d’URL qui n’existent pas sur le site, parce que la structure «URL hiérarchique» les fait partir dans des délires absolus et des URL de plus en plus longues. Et comme ce sont des URL qui n’«existent» théoriquement pas sur le site, pour le coup il n’y a aucun cache sur ces URLs, donc charge encore pire. Possibilité ici: compter les slash dans l’URL appelée, et répondre illico avec une erreur quand le nombre est trop élevé (par contre risque de surblocage si nombre trop bas) – je l’ai fait sur un site qui ne tenait plus, ça a premis de reprendre le contrôle du serveur. Éventuellement renoncer à «URL hiérachisées», donc ne plus compter sur <base href>, et ainsi éviter de fabriquer ces milliers d’URL inexistantes parce que ces bots sont codés avec le cul (ça ne dit pas qu’ils ne passeront plus, mais ça sera moins pénible puisqu’ils aspireront moins de pages, et que ces pages auront certainement un cache dans SPIP).
Sinon sur un de mes sites, j’ai bloqué tout le bloc des IP des fournisseurs d’accès officiels chinois. Ça a fait un peu de bien pendant un moment. Effet annexe bienvenu: le compteur de visites a redonné des valeurs un peu cohérentes.
Sinon sinon, les hébergeurs se plaignent, alors qu’ils savent parfaitement d’où vient le problème, et qu’ils laissent les «petits» webmestres se démerder tout en leur envoyant des mails vaguement menaçants parce qu’il y a trop d’appels à la base de données.
Chez nous on repère les bots débiles par leur incapacité à comprendre le base href et on flag leur IP immédiatement pour leur répondre ‹ fuck ›. Mais un jour ils vont corriger ça certainement…
