====== Commit 2007-08-07 ====== ===== Modifs ===== ==== Script "stats.py" ==== === Contexte === J'ai mis au point un nouveau script python qui va nous permettre, à terme, de nous passer du fichier CPU de la batterie. L'idée est d'avoir un moyen automatique pour vérifier le bon déroulement des commits et identifier les problèmes. Ces problèmes peuvent venir du CPU, de la mémoire utilisée qui peuvent subitement augmenter suite à une modif. dont on n'a pas mesuré les conséquences. Le fichier CPU jouait ce rôle depuis maintenant un bon bout de temps mais il a de nombreux défauts: * On oublie de le mettre à jour - principalement parce que cette mise à jour peut être laborieuse, surtout quand on ajoute ou retire des nouveaux tests. * Le fichier grossit et devient difficilement lisible (pas de graphique) * Le fichier ne concerne qu'une seule machine (chinook). Or on sait que certaines modifs peuvent influencer uniquement un type de machine. De plus, il serait intéressant de comparer les différentes machines entre elles. * Le système dokuwiki étant bugué (ou protégé contre l'upload abusif?), la mise à jour du fichier excel n'est pas possible à travers le réseau. * Le fichier CPU ne concerne que le CPU (d'où son nom). Il serait utile de garder trace d'autres grandeurs telles que la mémoire utilisée. Bref, c'est la galère et, vu la flexibilité du nouveau script de batterie (''battery.py''), j'ai décidé de coder un système automatique en suivant le même type de schéma, en python. === Les prérequis === Pour voir apparaître les beaux graphes sur votre écran, il vous faudra [[http://gnuplot-py.sourceforge.net/|Gnuplot.py]] (installé dans votre ''site-packages'' de python) et [[http://www.gnuplot.info/|gnuplot]] dans votre ''PATH''. Plus tard, je migrerai certainement le code vers [[http://matplotlib.sourceforge.net/|matplotlib]] qui a l'air franchement mieux fait. === Comment ça marche? === Plusieurs modes de fonctionnement sont possibles. Tapez ''stats.py'' en ligne de commande pour avoir l'aide. == Extraction du CPU total au cours du temps sur une machine == La première utilisation est d'extraire une courbe de temps CPU: stats.py -plot sum apps\verif\CPU-OSF1-All.txt on appelle la commande ''sum'' sur le fichier ''apps\verif\CPU-OSF1-All.txt'' et on choisit un graphe gnuplot par l'option ''-plot''. Après avoir fait quelques accès SVN, le script donne ca: {{ commit:2007:stats01.png |}} On voit donc l'évolution du temps total de la batterie sur chinook de révision en révision (en abscisse, les numéros de révision et en ordonnée, le temps CPU en secondes). Si quelqu'un est fan de gnuplot, il peut améliorer le graphe pour moi. Pour ceux qui trouvent ça lent, il peuvent se rassurer: le script met en cache tous les accès SVN (dans le répertoire ''.cache/'') et l'appel suivant est donc beaucoup plus rapide que le premier. Au cas où les accès SVN coincent, c'est certainement que votre svn est pas bien configuré. Je vous conseille d'ajouter un profil "gaston" dans votre putty, avec identification par clef publique/privée sans passwd et ajouter ces lignes dans votre fichier de config svn: [tunnels] ssh = C:/Program Files/putty/plink.exe Ca dit, en gros que ''svn'' (à installer - tortoise ne suffit pas) utilise le ''ssh'' de putty (nommé ''plink.exe''). Avant l'affichage du graphe, le script affiche une belle chiée d'infos sur toutes les versions rencontrées. Vous pouvez les lire: c'est très instructif. En voici un extrait: ... ==== parsing revision #99 by noels on 2007-07-06 15 largest absolute diffs: "apps.imp.long" : -46.5/703.7 (-6.6%) "apps.ie.tireSteering" : -45.9/427.9 (-10.7%) "apps.imp.taylor3dPk2Diss" : -43.6/2643.2 (-1.6%) "apps.qs.elbowModif4b" : -36.8/308.2 (-11.9%) "apps.bImp.cyl3D" : -25.7/1375.6 (-1.9%) "copraImport.tests.copraProfiling5.profilageUNoSym" : -20.7/1545.0 (-1.3%) "apps.bImp.cyl3DVP" : -18.2/885.7 (-2.1%) "apps.bImp.cylPlastLineSearchPk2Cons" : +15.6/218.3 (+7.1%) "apps.qs.dgShellFullPinchedCylinder" : +14.8/252.4 (+5.8%) "apps.bIe.aube3LineSearch" : -14.4/299.4 (-4.8%) "apps.bIso.soudureT" : +14.0/782.0 (+1.8%) "apps.imp.taylor3dPk2Cons" : -12.9/814.3 (-1.6%) "apps.imp.longHoriz" : -12.4/171.9 (-7.2%) "apps.ale.forge" : -11.5/102.8 (-11.2%) "apps.bIe.aube3" : -11.1/224.8 (-5.0%) 15 largest relative diffs: "apps.qs.elbowModif4b" : -36.8/308.2 (-11.9%) "apps.ale.forge" : -11.5/102.8 (-11.2%) "apps.ie.tireSteering" : -45.9/427.9 (-10.7%) "apps.ale.qsConv03" : -1.2/11.5 (-10.3%) "apps.complex.tombeBordEas2D" : -0.8/10.1 (-7.6%) "apps.ale.entonnoirAxyAle" : -8.7/116.0 (-7.5%) "apps.imp.longHoriz" : -12.4/171.9 (-7.2%) "apps.bImp.cylPlastLineSearchPk2Cons" : +15.6/218.3 (+7.1%) "apps.imp.long" : -46.5/703.7 (-6.6%) "apps.bQs.striction3dQs" : -0.6/8.9 (-6.6%) "apps.complex.contact3dDefoDefoAugLag2 (2)" : -4.1/67.5 (-6.1%) "apps.complex.contact3dDefoDefoAugLag3 (3)" : -3.8/61.8 (-6.1%) "apps.complex.contact3dDefoDefoAugLag2 (3)" : -3.3/54.5 (-6.1%) "apps.complex.tay2dExpPk2" : +10.2/171.9 (+5.9%) "apps.qs.dgShellFullPinchedCylinder" : +14.8/252.4 (+5.8%) "apps.monosMeca.membraneThirdDegree1" is a new test "apps.qs.dgSixteenNodeShellPinchedCylinder" is a new test "apps.qs.dgSixteenNodeShell" is a new test "apps.qs.dgSixteenNodeShellHemisphereWithHole" is a new test 4 tests added - 0 removed On voit donc que Ludo a ajouté 4 tests le 6 juillet et on peut voir les 15 plus grandes diffs en valeur absolue et relative. Si on veut pas toutes ces infos, il suffit d'ajouter l'option ''-silent'' à la commande. En interne, les diffs sont recalculées à partir des 2 révisions que j'extrais à l'aide d'un pipe à partir d'une commande ''svn cat''. Les numéros de révision à extraire sont récupérés à partir d'un ''svn log''. Les fichiers peuvent donc être triés de manière différente et ça marche toujours. == Comparaison du CPU total sur toutes les machines == Imaginons qu'on veuille maintenant comparer tous les CPUs sur toutes les machines: stats.py -plot -silent sum apps\verif\CPU-*-All.txt et hop! voilà le résultat: {{ commit:2007:stats02.png |}} On peut donc facilement comparer toutes les machines entre elles et, en particulier, identifier du premier coup d'oeil les commits de Pierre-Paul (quand la courbe "CYGWIN" rejoint celle de ''chinook''). Pour toutes ces courbes, le dernier point correspond à la révision sur votre disque. Elle prend donc en compte l'éventuelle batterie que vous avez lancée mais pas encore commitée. == Evolution d'un test au cours du temps == Imaginons maintenant que vous vouliez voir plutôt l'évolution d'un cas-test au cours du temps. Pour cela, il faut utiliser la commande ''history'' au lieu de ''sum''. Pour changer un peu, on ne va pas demander les CPUs mais plutôt l'évolution du nombre de pas de temps (''STP'') d'un test instable au cours des révisions (allez, ''tirGobin'', au hasard, rien que pour rire): stats.py -plot -silent history apps.exp.tirGobin apps\verif\STP-*-All.txt La commande ''history'' demande le nom du module en plus des fichiers "verif". On lance la commande et hop, voici le résultat: {{ commit:2007:stats03.png |}} Imaginons qu'on veuille maintenant exporter ces magnifiques gobineries sous excel... Pas de problème: il suffit de remplacer ''-plot'' par ''-txt'' et rediriger tout dans un fichier qu'on importera sous excel: stats.py -txt -silent history apps.exp.tirGobin apps\verif\STP-*-All.txt > gobin.txt où on n'a pas oublié le ''-silent'' sinon, la sortie contiendra aussi toutes les infos de parsing. Et voilà tout ça sous excel: {{ commit:2007:stats04.png |Gobineries sous Excel}} == Génération de l'ancien fichier CPU == Maintenant, il nous reste plus qu'à générer l'ancien fichier CPU en utilisant la commande ''details'' (au lieu de ''sum'' ou ''history'') qui ne prend qu'un seul fichier à la fois pour des raisons évidentes de clarté: stats.py -txt -silent details apps\verif\STP-OSF1-All.txt > cpus.txt Ca ne marche, bien-sûr qu'en mode ''-txt''. Et voilà, une fois importé: {{ commit:2007:stats05.png |Ancien fichier CPU auto-généré}} Il ne reste plus qu'à le mettre en forme si on veut le conserver ou tirer des courbes. ==== La suite ==== Pour la suite, je compte: * Changer de lib pour les graphes (''gnuplot'', c'est laid...). J'utiliserai certainement ''matplotlib''. * Appeler le script à partir de ''battery.py'' pour insérer les statistiques du commit en cours dans le mail de résultat de batterie. Pour ça, il faudrait idéalement faire un export HTML. Si vous avez des idées ou si vous trouvez des bugs, n'hésitez pas... \\ \\ --- //[[r_boman@yahoo.fr|Romain BOMAN]] 2007/08/07 17:24//