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

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

Discussion

2 discussions

  • Depuis mon passage en version 1.9, je suis souvent obligé de vider le cache de mon routeur pour accéder à mon site.

    Par ailleurs, une fois que j’ai vidé mon routeur, je suis aussi obligé de vider le cache de spip car je m’aperçois que des pages sont mal calculées.

    Qui a déjà rencontré ce problème ?

    Cordialement. BS

    Reply to this message

  • 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...).

    Quelqu’un pourrait -il développer un peu ce passage ci SVP ? J’avoue être super séduit par l’idée mais ne voit pas trop comment la mettre en place...

    Reply to this message

Add a comment

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite / PostgreSQL
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparait.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Who are you?
[Log in]

To show your avatar with your message, register it first on gravatar.com (free et painless) and don’t forget to indicate your Email addresse here.

Enter your comment here

This form accepts SPIP shortcuts {{bold}} {italic} -*list [text->url] <quote> <code> and HTML code <q> <del> <ins>. To create paragraphs, just leave empty lines.

Add a document

Follow the comments: RSS 2.0 | Atom