Version 2 — Mai 2012 — Beurt
Ceci est une ébauche que chacun est invité à compléter...
Voici une tentative de synthèse de ce que l’on peut lire ici et là pour aider chacun à optimiser son site sous Spip pour qu’il soit plus rapide.
Dans un premier temps, il faut préciser que Spip embarque déjà, sans ajouts particuliers, une multitude d’outils automatiques d’optimisation des performances [1]. Cela signifie que la plupart des webmestres n’auront rien à faire pour obtenir des performances proches d’optimales. Mais, il y a certains cas, comme des sites à très fort trafic (combien ?... à définir), ou quand le(s) serveur(s) est(sont) sous-dimensionné(s), il est nécessaire de mettre la main à la pâte pour optimiser encore. Souvent, ces ajustements sont spécifiques du site, et c’est parce que leur généralisation n’est pas possible que ces méthodes ne sont pas intégrées par défaut dans Spip.
À partir d’une page de squelette (ex. : squelettes/sommaire.html), Spip va interroger la base de données pour récupérer le contenu nécessaire et construire une page HTML qu’il renvoie au navigateur. Ce calcul se fait en plusieurs étapes, notamment rappelées ici : http://www.spip-contrib.net/Optimisation-de-la-charge-serveur-SQL-et-var_profile
-* Première étape : la transformation du fichier squelette en code PHP.
Spip « compile » le squelette pour le transformer en code PHP contenant des requêtes SQL. Il transforme donc boucles et balises en code PHP/SQL capable d’effectuer dynamiquement les actions nécessaires pour construire la page HTML finale. Cette page PHP est ensuite mise en cache par Spip, c’est-à-dire inscrite sur le disque dur du serveur. Ce cache est le cache dynamique, car il contient du PHP qui devra être exécuté (et nécessiter du temps de calcul). Ainsi, cette étape de compilation n’est pas refaite systématiquement. Il est seulement nécessaire de la faire quand le fichier squelette lui-même a changé. Si seules les données de la base de données changent, mais pas le squelette, alors on pourra réutiliser directement ce fichier PHP. Par contre, si le squelette change, il est nécessaire de refaire la compilation. C’est ce que l’on provoque en indiquant « var_mode=recalcul » dans l’URL d’une page.
On peut connaître les temps de ces trois calculs (je cite : http://www.spip-contrib.net/Optimisation-de-la-charge-serveur-SQL-et-var_profile) :
<blockquote class="spip">
- ?var_profile=1 (service du cache)
- ?var_profile=1&var_mode=calcul (prise en compte des nouveautés de la base de donnée)
- ?var_profile=1&var_mode=recalcul (recompilation = prise en compte des modifications du squelette)
Quand un visiteur tente d’afficher une page d’un site sous Spip, il existe d’autres temps d’attente que ces temps de calcul :
- Le temps de téléchargement des éléments de la page,
- le temps de calcul des positionnements dans la page par le navigateur,
- et le temps d’exécution du JavaScript de la page par le navigateur.
#INCLURE
ou <INCLURE>
?- #INCLURE
- <INCLURE>
- la question des #MODELES
- la question du PHP directement dans les squelettes
- la question des balises #SESSION
- Le cache est déterminé par un temps de cache
- chaque URL avec des paramètres différents provoque la génération d’un cache spécifique
- chaque visiteur identifié provoque la génération d’un cache spécifique
- la question de la taille du cache vs performance
var_profile
et autres techniques- var_profile
- Page Speed
- http://www.webpagetest.org/
- memoization
- cache cool
- Fastcache
- Expresso
- fulltexte
- inclure ajaxload
- ?
Les plugins utilisent des pipelines ou rajoutent des « fonctions » et des « options ». Si les calculs rajoutés sont lourds, cela peut avoir un impact sur le site.
- mes_options à chaque hit
- mes_fonctions à chaque recalcul
- critères et index SQL
- Champs extra/jointures
- inclusions (factorisation)
- jointures
- ajax
-* la base sur spip.net : http://www.spip.net/fr_article997.html
à compléter, bien sûr !