SPIP - Contrib

[ar] [en] [es] [fr] [it]



Accueil du site > Documentation > Tutoriaux pour le code de SPIP

SPIP 1.9 - Comment fonctionnent les appels d’une page de la partie publique ?

samedi 4 mars 2006, par Cedric Morin. Dernier ajout mardi 7 mars 2006


Pour la partie privée, la notion de performance est secondaire car elle ne génére pas un trafic important.

Pour la partie publique, il faut imperativement optimiser la performance pour pouvoir servir un maximum de hit simultanes, tout en acceptant un certain nombre de fonctionnalités


L’organisation des fichiers n’est plus forcément dictée par une logique fonctionelle, mais aussi par une contrainte d’optimisation des chargements de fichier.

Le but est de ne charger que ce qui est strictement nécessaire.

Comment cela fonctionne-t-il ?

Le visiteur interroge une url titre.html

  • GET titre.html réalisé par le navigateur
  • SPIP regarde si le fichier CACHE/a/titre_jdsjfdfjskfl14564.gz
    • le nom a/titre_jdsjfdfjskfl14564.gz est calculé a partir de l’url, du dossier_squelette. C’est le $chemin_cache
      • les opérations de cette étape sont traitée dans ecrire/public/cache.php
  • si la page en cache n’existe pas ou est perimée
    • si le squelette compilé CACHE/squelette/titre.php n’est pas disponible
      • phase de COMPILATION du squelette
        • le squelette titre.html est chargé
        • il est compilé dans CACHE/squelette/titre.php
          • transformation des boucles, balises … en code php
    • Phase de CALCUL du squelette compilé CACHE/squelette/titre.php
      • le fichier php est executé pour produire le fichier CACHE/a/titre_jdsjfdfjskfl14564.gz a jour
  • le fichier CACHE/a/titre_jdsjfdfjskfl14564.gz est evalué pour prendre en compte le code php restant (code php inclus dans les squelettes notamment)
    • Opérations réalisés par les scripts de ecrire/public/
  • un post rendu est réalise pour certaines operations spéciales (ex:surligner les mots de var_recherche pour servir une page apres une recherche)

Les accès à la base de données n’interviennent qu’a compilation/calcul. Ces accès sont couteux, et ils sont donc à éviter dès que la page calculée est en page.

Bon a savoir !

  • La requête var_mode=calcul provoque un CALCUL du squelette compilé présent en cache
  • La requête var_mode=recalcul provoque une COMPILATION du squelette puis son CALCUL

Les invalideurs

Ils sont gérés dans une table spip_cache
Tout un tas d’invalideur existent, liés chacun a un type d’évènement.
Ils servent à invalider toutes les pages liées à l’invalideur
Lorsque l’évènement propre à l’invalideur - un nouveau message dans un forum pour un invalideur forum - arrive, toutes les pages liées sont supprimées du cache.

Dixit _fil_, ca gagne a être connu, mais c’est pas encore super clair pour moi … Donc je vous en dis pas plus pour le moment !

Les subtilités du cache

Dans la 1.9, la gestion du cache prend en compte l’url par laquelle la page est demandée, le nom du fichier fond (une même page peut donc être servie par des fonds différents sans problème de cache), le dossier squelette (permet de personnaliser tout le design du site en fonction du profil utilisateur (cookie, navigateur, utilisateur identifié, adresse IP...).
Applications pratiques :
Proposer des habillages différents du site en fonction du nom de domaine par lequel il est appelé, pour un site multi-enseignes par exemple
Proposer des fonctions supplémentaires sur un site « corporate » pour les personnes qui surfent depuis l’adresse IP de la sociéte
Restreindre l’accès du site à une partie des visiteurs


Répondre à cet article



Suivre la vie du site RSS 2.0 | Plan du site | Espace privé | Charte et vie SPIP-Contrib | SPIP | L'autre.net