J'ai récemment un problème sur un site sous SPIP à très forte charge ( plusieurs dizaines de milliers de visiteurs chaque jour, imaginez le nombre de pages vues ).
Le problème apparaît lorsque le cache expire. La page est donc recalculée, cachée et ensuite envoyé à l'internaute. Seulement ce processus se déroule pour plusieurs internautes en même temps car le temps de recalcul est trop long. Donc tous les internautes qui arrivent entre le moment où la page est recalculée et le moment où elle est mise en cache, vont effectuer eux aussi un recalcul de la page ce qui va ralentir le premier recalcul et du coup par effet boule de neige, le serveur va saturer complètement.
Comment peut on corriger le cache de SPIP pour l'améliorer sur cet aspect ?
Créer une entrée par page dans la base de données qui indique si le squelette est déjà en recalcul ?
Créer un fichier texte par page dans un dossier spécial portant le md5 de la page en guise de nom de fichier, et si le fichier est présent c'est que le squelette est déjà en recalcul ?
Si un squelette est déjà en recalcul, on renvois la version en cache, sinon on le recalcul effectivement.
Je ne sais pas quel est la meilleure solution, qu'en pensez vous ?
Cordialement,
Yannick
PS: si ce n'est pas la bonne liste, merci de me dire sur laquelle je dois poster ce problème
Tout système de cache permet une amélioration des performances du système de base auquel il s'ajoute, mais ne saura jamais transformer une 2cv en ferrari. Autrement dit, il faut que le système sans cache soit capable de fonctionner correctement.
Je ne pense donc pas que ton problème vienne du système de cache de SPIP en lui même, mais plutôt, au choix,
- d'un sous dimensionnement de ton serveur
- de squelettes non optimisés qui génèrent des requêtes beaucoup trop lourdes et longues.
A ce titre le système de cache améliore sans doute très nettement la performance de ton site, mais il ne peut pas empêcher le calcul occasionel des pages, et il ne faut donc jamais oublier que celui-ci doit en toute circonstance rester acceptable pour ton serveur.
Raisonner autrement en essayant de faire en sorte que le cache compense tout cela est une erreur de conception qui conduit à déployer des usines à gaz sur la gestion du cache qui au final viennent augmenter la charge du serveur sans gain évident. C'est une impasse.
Pour information, SPIP, et son système de cache tel qu'il existe, ne pose aucun problème pour passer le seuil de 100000 visites/j sur un serveur unique, et même avec un site qui utilise des pages dont le contenu dépend de l'internaute identifié.
Ton problème précis peut donc sans aucun doute être résolu sans toucher à SPIP, mais nécessite très certainement une analyse du système et l'identification des goulots d'étranglement en terme de performance.
Désolé de te contredire Cédric, mais Yannick a raison. J'avais repéré le problème, qui est bien connu en informatique théorique, et à l'époque où on travaillait sur la 1.8 j'avais introduit en même temps que le nouveau compilateur un nouveau système de cache qui résolvait le problème. Fil avait eu des pbs de perf sur le diplo et avait remis l'ancien. Pour moi le pb reste ouvert et est un des aspects où SPIP n'est pas à la hauteur.
Désolé de te contredire Cédric, mais Yannick a raison. J'avais repéré le problème, qui est bien connu en informatique théorique, et à l'époque où on travaillait sur la 1.8 j'avais introduit en même temps que le nouveau compilateur un nouveau système de cache qui résolvait le problème. Fil avait eu des pbs de perf sur le diplo et avait remis l'ancien. Pour moi le pb reste ouvert et est un des aspects où SPIP n'est pas à la hauteur.
Committo,Ergo:Sum
Je ne connais pas l'historique des discussions techniques et des choix faits par le passé là-dessus, mais le simple fait que des calculs en doublons soient effectués dans ce cas est un défaut d'optimisation du fonctionnement du cache.
Comme tu le dis, ça me semble être un souci classique (qu'on rencontre aussi en algorithmique distribuée).
Le souci peut apparaître également (bien qu'avec une faible probabilité) sans que le serveur soit sous-dimensionné, et même si ça n'a pas un impact important sur les perfs, c'est pas optimal.
Pour ma part je rencontre le même souci par moment en raison de différentiels de charge très importants suivant les périodes sur le site que j'administre, et je n'ai pas forcément la possibilité d'upgrader le serveur pour le moment, donc un coup de pouce de ce côté-là dans une future version ne serait pas de refus.
travaillait sur la 1.8 j'avais introduit en même temps que le nouveau
compilateur un nouveau système de cache qui résolvait le problème. Fil avait
eu des pbs de perf sur le diplo et avait remis l'ancien.
j'avais aussi et surtout un problème dit de "code illisible"
je pense qu'avec le code actuel il ne serait pas difficile de remettre
ce genre de lock ; voire même, si la page est très longue à
recalculer, envoyer une page temporaire qui se recharge après x
secondes
Pour moi le pb
reste ouvert et est un des aspects où SPIP n'est pas à la hauteur.