#CACHE - SPIP
Article mis en ligne le 29 juin 2016
dernière modification le 26 janvier 2017

Petit article pour expliquer à quoi sert le cache et quand le vider (n’est ce pas Brigitte...)

 Principe Général

Tout le contenu d’un site géré sous SPIP est installé dans une base de données MySQL. Pour présenter ces informations aux visiteurs du site, il faut donc réaliser l’opération qui consiste à lire les informations, à les organiser et à les mettre en page, afin d’afficher une page HTML dans le navigateur Web.

un système de cache permet de stocker chaque page et ainsi d’éviter de provoquer des appels à la base de données à chaque visite. Non seulement la charge sur le serveur est réduite, la vitesse très largement accélérée, de plus un site sous SPIP reste consultable même lorsque la base MySQL est plantée .

Pour faire simple, il existe différents caches permettant de générer les différentes pages aux visiteurs plus rapidement, dans une optique de performance : on garde à portée de main les données qui sont souvent accédées, ou longues à calculer.

  • Cache des squelettes
    Un des caches essentiels est celui des squelettes : le résultat de la compilation d’un squelette, donc le code PHP généré, est mis en cache dans le répertoire tmp/cache/skel. Ce cache a une durée de validité illimitée.

Il sera recréé, pour un squelette donné, uniquement si :
le squelette d’origine est modifié (en se basant sur la date du fichier sur le disque),
le fichier mes_options.php ou mes_fonctions.php est modifié,
le paramètre var_mode=recalcul est passé dans l’URL,
le cache est manuellement vidé.

  • Cache des pages

Un second niveau de cache est celui des pages demandées par les visiteurs du site. Leur résultat est sauvegardé, dans les répertoires tmp/cache/0 à f/ avec une durée de validité. Ces fichiers sont répartis dans plusieurs dossiers car dans un seul, leur nombre pourrait devenir trop important et avoir un impact sur les performances du système de fichiers du serveur. À noter que les fichiers de plus de 16ko sont automatiquement compressés (gz) si PHP dispose de la fonction gzcompress().

Ce cache est recréé lorsque :
la durée de validité a expiré (définie dans les squelettes par #CACHE ou en son absence par la constante _DUREE_CACHE_DEFAUT),
le contenu éditorial de la base de donnée a été modifié. SPIP s’appuie sur la date de dernière modification pour le déterminer ($GLOBALS[’meta’][’derniere_modif’]) renseignée par la fonction suivre_invalideur() de ecrire/inc/invalideur.php,
le paramètre var_mode=calcul est passé dans l’URL.

  • Cache SQL
    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. Deux caches sont ainsi créés.
    • Cache des métas
      Le premier est un export complet de la table SQL spip_meta.
    • Cache des descriptions SQL
      Le second cache concerne la description des tables SQL des bases de données. Ces descriptions sont stockées dans les fichiers tmp/cache/sql_desc*.tx
  • Cache des plugins
    Des fichiers de cache spécifiques aux plugins sont aussi créés dans tmp/ ou dans tmp/cache/.
    SPIP met pour cela en cache, dans le fichier tmp/cache/chemin.txt, l’ensemble des correspondances entre un fichier demandé et son emplacement réel trouvé dans un des chemins.
    Ainsi, lorsqu’un fichier est demandé, SPIP cherche si le chemin est en cache. Si ce n’est pas encore le cas, il calcule son emplacement et enregistre le tableau de correspondance enrichi du nouveau fichier.

Ce fichier de cache est recréé par l’appel du paramètre var_mode=recalcul dans l’URL, ou par une vidange manuelle du cache

  • Cache des chemins
    SPIP utilise différents dossiers pour rechercher les fichiers qui lui sont nécessaires.
  • Caches CSS et Javascript
    L’extension « Compresseur » présente dans SPIP permet de compacter les différents éléments CSS et Javascript pour limiter le nombre d’appels sur le serveur et la taille des fichiers à obtenir.

Ces fichiers sont mis en cache dans local/cache-js/ et local/cache-css/. Ces caches sont recalculés si le paramètre var_mode=recalcul est passé dans l’URL.

Il n’est pas utilisé sur paroisse-benet.fr

  • Cache des traitements d’image
    SPIP dispose d’une librairie de filtres graphiques permettant par défaut de pouvoir redimensionner des images facilement.

Afin d’éviter de recalculer plusieurs fois des traitements extrêmement gourmands, SPIP stocke les résultats des calculs effectués dans les répertoires local/cache-gd2 et local/cache-vignettes.

Ces images en cache ne seront effacées que lorsque le cache des images est vidé depuis l’interface de SPIP ou lorsque le paramètre var_mode=images est transmis dans l’URL.

 Actualisation du cache
Lors d’une utilisation normale de SPIP, avec des visites, des nouveaux articles publiés, le cache et l’actualisation des données est correctement géré. Par défaut (mais des plugins pourraient modifier ce comportement), dès que SPIP a connaissance de modifications des contenus éditoriaux dans la base de donnée, il invalide tout le cache des pages.

[(Il est souvent nécessaire de vider le cache manuellement lorsqu’on effectue des modifications directement sur les fichiers, particulièrement en mettant à
jour une feuille de style ou un script Javascript calculés par des squelettes SPIP si les options de compressions sont actives.)]

Se rappeler que :

  • var_mode=calcul dans l’URL actualise le cache de la page
  • var_mode=recalcul (pour des administrateurs) dans l’URL recompile le squelette puis actualise le cache de la page.
  • passer sur la page de gestion des plugins ecrire/ ?exec=admin_plugin recalcule les fichiers de cache tmp/cache/charger_*.php des plugins, soit les listes de fichiers d’options, de fonctions et de pipelines.
  • le navigateur a son propre cache, que ce soit pour les pages ou pour les éléments AJAX. Il faut aussi penser à le vider ; ce n’est pas forcément SPIP qui ne retourne pas les contenus attendus, mais peut être le navigateur qui retourne son cache.

 Configurer le cache

[*Le cache des pages est défini à une journée,*]

  • Taille du cache,
    SPIP s’arrange pour que le cache ait une taille ne dépassant pas une certaine valeur, qui est de 10Mo par défaut. La variable globale $GLOBALS[’quota_cache’] permet de changer cette valeur, en mettant par exemple 100Mo :

[(Donc Que faire en cas de problème d’affichage du site SPIP ?)]
Vous constatez un dysfonctionnement dans l’affichage de votre site. Que faire ?

1° Avant toute chose, Actualiser la page dans le navigateur

Il se peut en effet que votre navigateur ait encore l’ancienne version des CSS ou du javascript.

Pour cela :
un clic dans la barre d’outil sur le bouton de rechargement/recyclage ou un appui sur la touche F5

2° Recalculer la page qui pose question

Une fois que vous êtes identifié sur le site, vous disposez dans l’espace public des boutons d’administration.

Cliquez sur le bouton Recalculer cette page.

3° Erreur dans les plugins

S’il y a un bandeau sombre en haut de l’espace d’administration commençant par « Erreur dans les plugins », il suffit d’aller voir la page de gestion des plugins : ecrire/ ?exec=admin_plugin.

4° Vider le cache de SPIP

Pour vider le cache de SPIP, rendez-vous dans ecrire/ ?exec=admin_vider, et cliquez sur le premier bouton Vider le cache.

5° les grands moyens
Vider sans souci les dossiers /tmp/ et /local/

 /tmp/
Ce répertoire contient les fichiers temporaires, de caches et de log, non accessibles par HTTP. On retrouve dedans un dossier spécifique :

  • pour le cache (cache),
  • un autre pour les sauvegardes (dump),
  • pour les sessions des visiteurs enregistrés (sessions),
  • pour les documents envoyés par FTP (upload)
  • ou encore pour calculer les statistiques des visites (visites)

 /local/
Le dossier local/ comporte de nombreux sous-dossiers dont :

  • local cache-css
  • cache-gd2
  • cache-js
  • cache-texte
  • cache-thumbsites
  • cache-vignettes

[**Vous pouvez alors visiter votre site et constater que tout va bien.*]


Dans la même rubrique

Dns & Hébergeur + Cms
le 29 juin 2016