Olivier G. a écrit :
De la part de Cédric MORIN
Envoyé : mardi 22 janvier 2008 21:29
Ce genre de considérations n'apporte pas grand chose si ce n'est alimenter un troll justement.
En tant qu'hebergeur tu dois savoir que le temps de chargement perçu par l'utilisateur est très différent de la capacité de service du serveur et des ressources nécessitées.
Commençons par du concret avec une url de chaque exemple ?
Oulà. Si on reçoit toutes les bonnes volontés chez les hébergeurs aussi
froidement, je ne suis pas certain qu'on va en garder beaucoup...
héhéhé, faut dire que l'entrée en matière genre "j'aime pas ce que vous faites, mais je suis obligé de l'utiliser" était pas mal non plus.
Concretement, il faut bien comprendre ce qui se passe pour savoir ce qu'on mesure, surtout si on compare à d'autres produits.
Dans Spip, vu du serveur, il y a plusieurs choses :
1- la compilation des squelettes : cette operation n'est faite qu'une fois, il faut donc l'exclure des tests et travailler sur des squelettes compilés.
2- le rechargement du cache : il n'est fait qu'une fois toutes les X secondes ou invalidation (modification)
=> execution du squelette compilé => traitement PHP + acces base de donnée + ecriture des fichier (vient en plus de l'etape suivante)
3- l'assemblagede la page : c'est le plus important à mesurer, c'est ce qui est fait à chaque hit
=> lecture de fichiers (plus ou moins nombreux selon les squelettes) + execution si il y a du PHP ou des balises dynamiques dedans
4- le "SPIP_CRON" : si il reste du temps d'execution après avoir servit la page, Spip execute ses taches de fond (nettoyage, envoi de mails...), ce qui charge le serveur mais ne comptera pas dans le temps de chargement de la page pour l'utilisateur.
les points 1 et 4 sont amha à exclure des tests
Pour simuler une utilisation, il faut donc jouer un scenario qui fasse appel aux points 2 et 3 dans des proportions proches de la réalité.
Mais ces proportions varient selon les squelettes et l'utilisation.
sur un site à fort trafic mais se concentrant sur le meme contenu, le cache jouera pleinement son role et et la page ne sera rechargée qu'une fois sur 1000.
Alors qu'avec le meme trafic, un autre site, recalculera peut etre en moyenne toutes les 3 affichages car les visiteurs visiteront des pages differentes.
Quand on se situe au niveau de l'hebergeur, on voit bien que le "pire", c'est plein de sites avec peu de trafic : les pages sont recalculées quasiment à chaque fois => pas d'utilisation du cache
Mais le gros avantage, c'est que plus le trafic d'un site augmente, plus le ratio recalcul/utilisation du cache diminue.
Pour faire un test réaliste, il faut donc faire varier ce ratio en meme temps qu'on augmente la charge.
mais dans quelle proportion ? de combien à combien ?
il faut voir en moyenne combien de fois chaque page est appelée par heure et savoir comment sont reglés les caches pour connaitre le ratio
ca depend des sites hebergé...
En plus, chaque squelette, chaque inclusion, définissent les temps de mise en cache et la complexité des requete au recalcul.
Si je fais une grosse boucle récursive avec 3 boucles contenant des regexp dedans et que je mets un cache à 0, forcement, ca va etre tres gourmand !
A coté de ca, je peux faire un cache recalculé toutes les semaines pour faire mon menu...
Bref, Spip etait plus proche d'un langage que d'un produit, on peut auditer le code (les squelettes) pour voir s'il n'y a pas de mauvaises pratiques, en optimiser certains au niveau de l'algorithme, d'autre sur l'exploitation du cache, mais je ne vois pas en quoi ca aiderait à optimiser Spip lui meme.
Je pense que les hebergeurs souffrent plus de mauvaises utilisation que du code lui meme.
Le code lui meme est sans doute optimisable, mais je ne pense pas que l'observation de sites en prod renseigne beaucoup, sauf grosses boulettes de construction de requetes.
C'est plutot de la reflexion sur les des cas particuliers qui pourrait aider à optimiser le "moteur"
mes 2 sous.
@++
