optimisation SPIP-contrib J1

Je (ou peut être « on ») vais essayer de faire un ensemble de billets sur SPIP-Contrib. Après tout, à l’origine, ce blog avait pour vocation de raconter un peu la vie de spip-contrib.

Donc ici on part d’un « troll », d’une « légende », d’un « fait », d’une « rumeur » (à vous de choisir) qui dit que SPIP-contrib est lent .

Aujourd’hui SPIP-Contrib est hébergé chez l’autre, et aujourd’hui j’ai eu la preuve que l’autre assurait bien ;-)

Afin de pouvoir regarder comment optimiser spip-contrib, un envirronement de test est mis en place : un dump de la base , le dossier squelette IMG et enfin le squelette disponible sur la zone et l’affaire est dans le sac .

Une fois ceci fait, le premier constat est de dire que SPIP-contrib sur le serveur de bench est LENT (très lent).

Détaillons un peu pourquoi avec des chiffres sur spip-contrib :

Spip-contrib en quelques chiffres (dec 2007) :
– 1800 articles
– 100 breves
– 6000 auteurs
– 5000 visites par jour (stats spip)
– une base de données de 400 mega
– 350 Meg dans le repertoire IMG

Enfin l’autre constat du jour ( en ajoutant ?var_mode=recalcul&var_profile=1 à la fin de l’url) est de constater que pas moins de 1206 requetes sql sont passées lors du recalcul de la page sommaire .

Un petit exemple sur le serveur de test : les 4 requetes les plus longues prennent 6 secondes
– 1 : 2.12 s
– 2 : 1.88 s
– 3 : 1.14 s
– 4 : 0.97 s

et quand on regarde l’une de ces requetes

 SELECT syndic_articles.id_syndic_article, syndic_articles.id_syndic
FROM <span class="base64" title="PGNvZGUgY2xhc3M9InNwaXBfY29kZSBzcGlwX2NvZGVfaW5saW5lIiBkaXI9Imx0ciI+c2NyX3NwaXBjb250cmliPC9jb2RlPg=="></span>.spip_syndic_articles
AS <span class="base64" title="PGNvZGUgY2xhc3M9InNwaXBfY29kZSBzcGlwX2NvZGVfaW5saW5lIiBkaXI9Imx0ciI+c3luZGljX2FydGljbGVzPC9jb2RlPg=="></span>
INNER JOIN <span class="base64" title="PGNvZGUgY2xhc3M9InNwaXBfY29kZSBzcGlwX2NvZGVfaW5saW5lIiBkaXI9Imx0ciI+c2NyX3NwaXBjb250cmliPC9jb2RlPg=="></span>.spip_syndic
AS L1 ON syndic_articles.id_syndic=L1.id_syndic
WHERE (syndic_articles.id_syndic = 278)
AND ((syndic_articles.id_syndic_article
NOT IN (0,2431,2432,2433,2434,2435, .............

il n’y avait pas moins de 6500 occurences de NOT in ... pas étonnant que mysql souffre !

Donc bilan de la journée : on prend conscience qu’on travaille sur un gros morceau ;-)

Reste pour la suite à se fabriquer des petits outils de tests de perf afin d’essayer de mesurer le gain de chaque changement entrepris (squelette, amaigrissement de la base, utilisation de phpaccelerator .... )