Expresso

Fonctionnement

Pour être percolée, une page doit contenir la directive
#HTTP_HEADER{X-Expresso: true}

Le plugin fabrique un cache statique de toutes les pages percolées, qu’il stocke dans un repertoire « tmp/cache/apache », et maintient une liste de correspondance (url,fichier).

Pour initialiser l’expresso, il faut ajouter la chaine XXXEXPRESSOXXX dans le fichier .htaccess situé à la racine du site. A cet endroit du .htacess, Expresso intègrera les directives de RewriteRules qui dirigeront l’appel de la page soit vers la page ellemême de temps en temps pour recalculer le cache, soit vers le cache statique correspondant à la page.

A priori, c’est plutôt à la fin du .htaccess qu’il faut insérer ce marqueur, mais pas nécessairement tout à la fin...
Si vous avez les url_standard (canal historique), il faut mettre le marqueur #XXXEXPRESSOXXX juste avant la ligne

RewriteRule ^(rubrique|article|breve|mot|auteur|site|agenda|backend|backend-breves|distrib|forum|ical|plan|recherche|resume|sommaire_texte)\.php3?$	spip.php?page=$1 [QSA,L]

En effet, si des régles expresso pour des articles par exemple, étaient positionnées après ce bloc, elles ne serait jamais utilisées puisque ledit bloc transforme les requêtes ?article.php en requêtes ?spip.php

Les rewriterules intègrent une condition temporelle afin de répartir le service entre Apache et SPIP : c’est le percolateur qui appele les fichiers du cache, mais laisse tout de même passer une petite partie des requêtes à SPIP pour assurer la mise à jour des pages expirées.

Cette proportion de requêtes qui va vers le cache peut être spécifiée entre 0 et 60. Il faut pour cela modifier le fichier « expresso_pipeline » à la racine du plugin. Pour une valeur de 0, le cache statique est désactivé, pour 60, tous les appels renvoient la page en cache : il n’y a plus aucun appel à PHP, mais la page n’est plus jamais raffraichie !

La gestion de ce poursoixantage se fait quasi-aléatoirement sur la base de la valeur de la seconde à laquelle la page est appelée (d’où l’intervalle 0-60), et donc la proportion est approximative. Mais pour une page qui est beaucoup appelée (cas le plus intéressant pour un cache statique), statistiquement, ça doit être vite très approchant de la proportion ciblée.

Ce qu’on peut vérifier quand ça marche :

Le cache statique n’est jamais servie à un admin. Pour tester, il faut donc supprimer le cookie de liaison et vous déconnecter de la partie privée, et charger les pages jusqu’à ce que le délais de recalcul soit atteint et provoque l’écriture dans le htaccess... Ou alors attendre que les utilisateurs aient eux même provoqué cela !

On voit, dés les premiers appels des pages, les fichiers caches se fabriquer dans /local/apache

Par ailleurs, le fichier de log /tmp/boost.log mémorise les derniers caches statiques créés.

Après un certain temps dépendant de la valeur de la directive #CACHE spécifié dans vos squelettes, le htaccess est modifié et intègre la rewriterule qui appelle le cache.

Ensuite, on peut consulter les headers http des pages, par exemple avec l’option du plugin webdeveloper de Firefox. Ces headers sont différents sur les pages sans expresso, sur les pages percolées mais servi par le php, et sur les pages percolées servies à partir du cache statique :

-  le header des pages non percolées contient notamment : X-Spip-Cache: 86400 (par exemple). Elle contient également l’indication du php : X-Powered-By: PHP/4.4.7 par exemple, ainsi que, si le service est gzipé : Content-Encoding: gzip.

-  le header des pages percolées mais servies par php (par exemple parceque vous êtes admin, ou parceque c’est un moment de recacul du cache) contient en plus :
X-Expresso: true. (et, autre différence : il n’y a plus de gzip )

-  le header d’une page percolée et servie directement à partir du cache statique est différente : il n’y a plus l’indication que la page est servie par php, et il n’y a plus le header x-expresso.

Ces petites différences permettent de tester et vérifier si ça marche...

Statistiques de fréquentation

Les statistiques SPIP d’une page percolée ne sont pas du tout valables puisque SPIP n’en voit passer qu’une faible part.

Par contre, les statistiques utilisant des marqueurs externes, comme Xiti ou GoogleAnalytics, continuent à marcher.

Exemples d’appel

Il est possible d’appeler Expresso sur toutes les pages d’un site, mais si vous en avez beaucoup, cela va encombrer le .htaccess. Alors il est préférable de ne l’appeler que pour les pages les plus appelées.

Si vous voulez percoler la page sommaire, il suffit de rajouter la balise en début du squelette sommaire.

Si vous voulez percoler certains articles, vous pourrez vous servir d’un mot clé à usage technique qui sera testé dans une boucle :

<BOUCLE_percole(ARTICLES){id_mot=19}{id_article}> 
#HTTP_HEADER{X-Expresso: true}
</BOUCLE_percole>

Cela aura cependant l’inconvénient que non seulement l’appel à la page sera percolée, mais aussi tous les appels secondaires qui passent par ce même squelette (par exemple : les paginations suivantes, les appels de forums ou de document, ...). Pour ne pas encombrer le .htaccess par ces pages secondaires peu visitées, il est souhaitable de les éliminer en testant les paramétres de l’url :

<BOUCLE_percole(ARTICLES){id_mot=19}{id_article}> 
    [(#EVAL{_request('debut_forums')}|?{'',' '}) 
        [(#EVAL{_request('id_document')}|?{'',' '}) #HTTP_HEADER{X-Expresso: true} ] ]
</BOUCLE_percole>

Pour le squelette des pages rubriques, il faudra en plus tester la pagination des breves, des articles et des sites ... (debut_breves, debut_articles, debut_sites... )

Si les conditions à tester sont trop nombreuses, il faudra définir un filtre pour les tester, car la grammaire spip ne permet pas les imbrications d’une trop grande complexité.

Un autre mécanisme de test pourrait être défini pour non pas exclure les pages parasites, mais ne retenir que LA page souhaitée. C’est d’autant plus souhaitable que des tas de programmes ou de sites sur internet appellent des pages de votre site, avec des paramétres dont vous avez vraiment pas idée... et que chacun de ces appels encombre inutilement le .htaccess

Pour ne retenir donc que les bonnes pages, vous pourrez utilement utiliser ce filtre qui teste le nombre de variables passées dans l’url :

function isgetokexpresso($texte, $cool=2)
{
//  count ($_GET) vaut basiquement 2 car après les redirections url_propre, on se trouve dans une page appelée par spip.php avec 2 parms : le nom de la page (article ou rubrique) et la valeur id_article ou id_rubrique
  return (count ($_GET)==$cool ? " " : "");
};

et l’appel donne quelquechose comme ça :

<BOUCLE_expresso(ARTICLES){id_mot=19}> 
    [(#NOOP|isgetokexpresso) #HTTP_HEADER{X-Expresso: true} ]
</BOUCLE_expresso>

Pour la page d’accueil (squelette : sommaire.html), il n’y a pas d’autres parametre que le nom de la page (=sommaire), donc l’appel se fera différemment :

[(#NOOP|isgetokexpresso{1}) #HTTP_HEADER{X-Expresso: true} ]

Attention

Les statistiques spip des articles percolés sont très très sousévaluées puisque seule une faible partie des pages appelées passent par spip. Les mesures statistiques sont donc fausses, ainsi que signalé précédemment.

On ne pourra donc pas utilement passer par une boucle SPIP testant la popularité des pages pour sélectionner automatiquement les pages percolées...

Test d’usage

-  test en situation de crise :

Expresso a déjà démontré ses capacités sur un pic d’audience, cf. spip-blog.net/SPIP-tient-la-route

Sur le graphe, les vides signalent que le serveur était tellement chargé que le monitoring, non prioritaire, n’a pu avoir lieu. Mais le site a tenu le coup et servi les pages demandées.

-  mesures :

Selon les mesures réalisées par l’hébergeur Lixium pour le site Passerelle Eco , la ressource CPU mobilisée pour le service d’une page percolée est de 100 fois inférieure
à celle requise pour une page non percolée. Sur ce site, les 30 pages les plus consultées, générant 70% du traffic sont percolées au moyen de boucles qui les sélectionnent en utilisant le filtre isgetokexpresso ci dessus. L’économie pour le CPU est significative.

Auteurs

Auteur du plugin : Cédric Morin http://www.yterium.net/
© 2007 - Distribué sous licence GNU/LGPL