Etude de performances 1.9b

Pour parler de performances, il faut des mesures et des interprétations ; tel est l’objet de ce compte rendu d’essais de comparaison entre Spip 1.8 et Spip 1.9 beta.

Pour sauter tout de suite à la conclusion, il est quasiment certain que les mesures de temps de la 1.9b ne sont pas meilleures que celles de 1.8. C’est dommage dans la mesure où l’introduction des Plugins devrait permettre un allègement du noyau censé se refléter dans les performances. Bien sûr, il faut donner du temps au temps et cet objectif n’est peut-être que simplement différé. On pourra aussi arguer que l’objectif n’est pas tant l’allègement du noyau que son maintien.

L’autre aspect de la question est quantitatif. La baisse constatée est-elle réelle et si oui est-elle importante ? Là, le débat est encore plus ouvert et les réponses dépendent du profil d’utilisateur : s’agit-il d’un visiteur, d’un rédacteur ou d’un hébergeur ?

NB : Le zip 1.8 pèse 2,4 Mo contre 2,6 pour 1.9b2, une augmentation qui ne s’explique pas forcément par l’ajout de traductions.

Le principe de mesure

La mesure est basée sur wget. Cet outil se comporte comme n’importe quel navigateur Web à ceci près que au lieu d’afficher joliment ce qu’il reçoit d’un site Web, il met brutalement l’information dans un fichier. Donc en mesurant le temps mis pour recevoir une page HTML, on mesure le temps de traitement par Spip coté serveur ainsi que le temps de transmission par le réseau que l’on peut en général négliger.

Il s’agit donc d’une mesure de temps, celui qui est réellement vécu par l’utilisateur. C’est l’ intérêt de wget par rapport à d’autres méthodes de mesure de temps comme ab (Apache bench). wget est disponible sur toutes les plate-formes (Windows, Linux...). L’autre intérêt de wget est que l’on peut lui indiquer d’un coup plusieurs pages à lire, ce qui permet d’enchaîner plusieurs mesures sans avoir à relancer l’outil, ce qui minore le facteur de perturbation de l’outil lui même dans une mesure de temps.

Pour une page de la partie publique, il faut distinguer 3 temps : celui de la compilation (elle a lieu 1 fois pour toutes), celui du calcul (de temps en temps, à chaque expiration du délai de cache) et celui de la lecture elle-même (systématique). Pour une page de la partie privée on ne mesure que la lecture.

La mesure

La mesure est faite en local, ce qui élimine les temps de transmission réseau, à partir d’une base correspondant à un site réel pour laquelle on retient un échantillon de quelques dizaines de pages. Pour la partie publique, c’est un savant mélange d’articles (45), brèves (11), rubriques (7), auteur (3) et plan (1).

On compare 1.9 par rapport à 1.8 avec 2 mesures de temps (t18 et t19). Le gain de performances est (t18 - t19)/t18 qui est négatif en cas de baisse de performances.

Le squelette retenu est le squelette standard de Spip (dist/). Il a évolué entre 1.8 et 1.9b mais étant donné que le dist de 1.8 fonctionne toujours sous 1.9b, on peut aussi l’utiliser dans les deux mesures pour une comparaison limitée au noyau de Spip.

Le gain tel qu’il est défini est censé être indépendant de la machine utilisée mais cela reste à confirmer avec une machine Unix du genre de celle utilisée par les hébergeurs (les mesures qui suivent sont faites avec un Unix type MacOS).

Par ailleurs, le gain peut être influencé par des facteurs non-déterministes ; il est donc important que les mesures soient effectuées dans des conditions aussi stables que possibles (lecteur mail, économiseur d’écran, Plugins Spip désactivés...) et proches. Malgré tout, il reste une "dispersion" dans les résultats essentiellement due au fait que l’OS dispose de ses propres caches, car, sur une série de mesure lancée à froid, la première valeur est toujours atypique.

Partie publique

SVN 6580 (10 juin 2006)

Note : compte tenu de l’échantillon (une majorité de pages d’articles basées sur le même squelette) la partie compilation de squelette peut être négligée dans le cas "sans cache".

A titre de comparaison, un historique sur 3 mois, avec la dist 1.8, pour différentes révisions 1.9 :

L’effet dist n’est pas négligeable.

Partie privée

Historique sur 3 mois pour différentes révisions 1.9 :

Entre 6402 et 6580 les performances sont nettement dégradées par ce qui se revèlera être un simple bug.

Mise à jour (15 Juin 2006) : en raison d’une erreur de mesure les % indiqués ici pour la partie privée ne sont pas significatifs, mais les conclusions restent inchangées (baisse de performances 1.9b , bug 6402 ).

Outillage

De petits outils permettent d’automatiser les mesures avec wget sous Shell Unix. Ils pourront être utilisés sur d’autres machines, avec une autre base SQL, en veillant à adapter s’il le faut le jeu d’URL fourni.

Ils sont disponibles sur Spip-zone et récupérable par svn. Consulter le README pour le détail.

Conclusions

Les conclusions ont été présentées en introduction mais on peut ajouter quelques remarques.

Une diminution de performances peut être acceptable si elle est compensée par de nouvelles fonctions, tant qu’elles sont profitables à tous, à savoir :

 amélioration du compilo
 pagination

Il existe plusieurs critères de performances : le temps à servir une page Web compte pour le visiteur tandis que le coût de calcul (ceci peut concerner la mémoire aussi) importe davantage coté serveur (point de vue hébergeur). Spip 1.9 apporte un plus certain aux hébergeurs en leur permettant de mutualiser le code ; ceci peut compenser cela.

Le temps de service d’une page d’une page Web dépend aussi du réseau ce qui atténue les chiffres de perte qui précèdent (point de vue visiteurs / rédacteurs).