Dans les leçons précédentes nous avons commencé à élaborer des squelettes. Le succès de notre site risque d’être fulgurant. Pensons tout de suite aux pauvres neurones de notre ordinateur. Dans cette leçon, rien d’amusant, rien d’essentiel non plus. Les flemmards en profiteront pour roupiller au fond près du radiateur...
Résumé pour ceux-ci et pour les gens pressés : dans les fichiers d’appel de type tutoriel.php3, réglez $delais = 3600 ; au lieu de 0.
...
Au moment où une page est demandée à SPIP, celui-ci regarde si,
par hasard, il n’aurait pas déjà calculé cette page auparavant.
Si l’URL demandée est http://votresite.net/tutoriel.php3?id_article=12,
SPIP regarde dans son sous-répertoire CACHE/ si ce fichier
existe, et, le cas échéant, compare l’âge du fichier caché aux
$delais fixés dans le fichier d’appel tutoriel.php3.
Dans notre exemple nous avions fixé des $delais=0 ; -
d’où un recalcul systématique des pages à chaque consultation du site.
Passons à $delais=3600 ; (c’est en secondes).
Notre page web n’est donc recalculée que si, lorsqu’un visiteur la
demande, sa version cachée date de plus d’une heure (soit 3600 s.).
Sinon, SPIP lit simplement le contenu du fichier caché [1],
et renvoie le résultat sans se connecter à la base de données
(sauf pour y insérer un « hit » dans les statistiques).
Comment fixer ces $delais de manière à optimiser
le rapport réactivité/charge du serveur ? Pas de solution miracle,
mais n’hésitez pas à fixer un délai d’une journée (i.e. $delais=24*3600 ;) ou
plus pour les articles et les rubriques. Les pages de navigation les
plus importantes peuvent avoir des $delais plus courts
(vingt minutes ou une heure par exemple) si votre site est censé
réagir à la validation fréquente de nouvelles brèves et de
sites syndiqués... Si vous êtes sur un serveur partagé avec d’autres
sites, soyez respectueux des autres et ne prenez pas tout le
temps de calcul pour des pages qui changent rarement :
ce serait d’autant plus idiot que, sur les gros articles ou sur
les sommaires, le calcul des pages peut prendre quelques
secondes, ce qui ralentit la consultation de vos pages...
Comment provoquer une mise à jour hors délai ?
Nous venons de décider de $delais extrêmement longs,
et nous repérons une fôte d’ortografe dans une page. Correction
dans le back-office... Comment effacer tout de suite cette
vilaine cicatrice du site ?
Depuis le back-office, cliquer sur « Voir en ligne » déclenche
le recalcul pour les pages correspondant à #URL_ARTICLE
ou #URL_RUBRIQUE de l’article ou de la
rubrique correspondante. C’est le cas le plus courant. Mais sinon ?
Dans la partie « Sauvegarde/Restauration » du back-office,
un bouton « vider le cache » efface tous les fichiers cachés
(utile si vous faites plein de modifications et avez un site très complexe,
à éviter sinon).
Toutefois, la solution la plus simple est de demander à SPIP, dans
la page d’accueil du back-office, de vous « poser un cookie ».
Ce cookie s’incrustera sur votre navigateur, et SPIP vous
reconnaîtra au moment de vous envoyer la page dans le site public :
il vous proposera alors, en bas de page, un bouton « Recalculer cette page ».
Retour au contexte : On revient ici à la notion de contexte.
Si le squelette est appelé avec un contexte d’id_article,
d’id_rubrique ou encore d’id_breve, un
autre bouton vous est proposé quand SPIP détecte le cookie :
« Modifier cet article (ou rubrique, ou brève) », qui vous mène
directement sur la page correspondante dans le back-office.
Merci qui ?
Derniers détails :
pour des raisons évidentes, le moteur de recherche ne
déclenche pas de cache, et les pages avec forum sont
réactualisées dès qu’une nouvelle contribution est envoyée.
le répertoire CACHE/ dans l’arborescence du site
est découpé en 16 sous-répertoires numérotés
0, 1, 2... 9, A, B... F, dans lesquels les
fichiers cachés se distribuent quasi-aléatoirement ; cela
s’appelle « hasher le cache » et rien que pour cela mérite
bien qu’on le mentionne.
les fichiers cachés sont exploités même si la base de données
est « tombée », ce qui garantit le site contre des pannes
transitoires du serveur mySQL.
