EXTENSION D UN OUTIL DE VISUALISATION DE TRACES

Transcription

1 ASR9 - Projet de Fin d Études EXTENSION D UN OUTIL DE VISUALISATION DE TRACES Encadré par: M. François TRAHAY Mayssem BOUZAZI Khalil JEBALI Octobre Janvier 2014

2 Remerciements Nous tenons à remercier sincèrement notre encadrant Mr François TRAHAY pour le temps qu il a consacré, son encadrement ainsi que ses précieux conseils. Nos remerciements s adressent aussi à tous les professeurs de la VAP d Architecte de Services informatiques en Réseaux pour l intérêt qu ils ont porté à notre travail. I

3 Résumé De nos jours, vu que son utilisation est de plus en plus fréquente, le calcul intensif ou HPC (pour High Performance Computing) nécessite la visualisation des traces d exécution afin d améliorer le plus possible les performances des applications développées. ViTE (Visual Trace Explorer), un outil à la fois fois simple et efficace, permet à l utilisateur de suivre l exécution d un programme afin d identifier rapidement les anomalies présentes et qui peuvent affecter son déroulement. Cependant, cet outil de visualisation permet de manipuler au plus un seul fichier à la fois qui est généralement en format Pajé et qui peut être lourd et illisible pour l utilisateur. C est pour cette raison qu il y a eu recours à un nouveau format de fichier (Pajé2) proche du format Pajé. ViTE étant incapable de visualiser un tel format et c est précisément là où se situe l objectif majeur de ce projet de fin d études : étendre ViTE pour pouvoir supporter ce format de traces. Mots Clés : HPC, ViTE, Traces d exécution, Pajé, Pajé 2, Parser. II

4 Table des matières 1 Visual Trace Explorer (ViTE) Formats de traces supportés OTF TAU Pajé Visualisation des traces avec ViTE Le Parser Le Render L interface Le projet Motivation Travail à effectuer Déroulement du projet Le format Pajé Gestion du multi-parsing Support des Patterns Optimisations de ViTE Difficultés rencontrées III

5 Table des figures 1.1 Exemple de trace d exécution visualisée sur ViTE Représentation simplifiée d une trace d exécution Interactions entre les différents modules de ViTE Algorithme du Parser Les différentes interactions du parser Schéma simplifié d une trace en format Pajé Schéma simplifié d une trace en format Pajé Structure d une PajéLine Structure d une Trace Fonctionnement du ParserPajé Exemple de trace au format Pajé Exemple de définition d un pattern en Pajé Exemple d appel de Pattern en Pajé Fonctionnement du ParserPajé modifié Structure d un Pattern Instanciation et sauvegarde d un pattern Sauvegarde des occurrences du pattern Parsing avec les valeurs moyennes Interactions Parser Render IV

6 Introduction Suite à l évolution de la demande en puissance de calcul pour diverses applications informatiques et l explosion en performance des nœuds de calcul qui l a accompagnée, le marché informatique du calcul intensif ou HPC (pour High Performance Computing) jouit d une croissance soutenue. Une ascension qui peut être expliquée par l évolution et la miniaturisation des composants électroniques et la baisse de leurs coûts. Une position encore fortifiée par l introduction des architectures parallèles qui permettent d amplifier la puissance de calcul tout en maintenant un bon rendement et en économisant de l énergie. C est pour cette raison que le calcul intensif est utilisé pour répondre à différents besoins dans divers domaines tels que la recherche académique, les projets gouvernementaux, la météorologie... De ce fait, les différentes architectures matérielles utilisées (processeurs multicœurs, GPU, grappes, nœuds de calcul...) qui sont devenues non seulement plus performantes mais aussi complexes ainsi que l utilisation de modèles de programmation hybrides compliquent les tâches d optimisation et d analyse des applications. Ce qui fait qu une simple inspection du code source n est plus suffisante pour mener une analyse intuitive de l exécution d une application, tâche qui s avère essentielle pour pouvoir améliorer ses performances. Ainsi, afin de faciliter la compréhension du comportement d une application, le développement des outils d analyse s est basé sur le suivi et l enregistrement des événements lors de l exécution à l aide d un type de fichiers en formats bien spécifiques qu on appelle les traces d exécution. EZTrace, un outil développé suite à une collaboration entre Télécom SudParis et Inria Bordeaux, permet de suivre l évolution des programmes en exécution et de générer des fichiers de traces sous forme textuelle que nous pouvons analyser. Cependant, plus les processus d exécution sont complexes, plus leurs traces d exécution deviennent lourdes, ce qui rend la tâche d analyse des traces générées sous forme textuelle difficile, voire impossible. Ce qui a mené à concevoir de nouveaux outils qui fournissent des résultats plus légers et plus lisibles pour l utilisateur et qui sont essentiellement sous forme graphique tel que ViTE (Visual Trace Explorer), un outil capable d interpréter certains formats de traces d exécution et de reproduire les données qu elles contiennent sous forme graphique. 1

7 Les travaux de recherche actuellement menés dans l équipe HP2 à Télécom SudParis visent à structurer différemment les traces d exécution afin d en réduire la taille et de consommer moins de mémoire RAM en les analysant. Néanmoins, ViTE ne permet de lire qu un certain nombre de formats de traces. C est précisément là où se situe l objectif de notre projet de fin d études : étendre ViTE pour pouvoir supporter de nouveaux formats. Le projet de fin d études, intitulé, s inscrit dans le cadre du module CSC5005 de la voie d approfondissement ASR. C est un projet qui s est étalé tout au long du semestre 9 de notre cursus sous l encadrement de Monsieur François TRAHAY, enseignant-chercheur à Télécom SudParis. 2

8 Chapitre 1 Visual Trace Explorer (ViTE) ViTE (Visual Trace Explorer), projet développé en OpenSource à l ENSEIRB sous licence CECILL-A, est un outil interactif de visualisation de traces d exécution pour une large variété d applications y compris les programmes parallèles et les applications distribuées. Il offre une interface graphique performante et facile à manipuler, permettant aux utilisateurs de l adapter à leurs besoins avec un ensemble de fonctionnalités et de plugins. Comme le montre la Figure 1.1, ViTE permet de représenter une trace sous forme de diagramme de GANTT représentant le déroulement de l application en fonction du temps. ViTE supporte essentiellement trois formats de fichiers de traces qui sont OTF, TAU et Pajé. Ces traces d exécution peuvent être générées en utilisant EZTrace (un projet de l INRIA qui permet la création des traces au format Pajé.) ou GTG (Generic Trace Generator : une bibliothèque qui offre une interface pour générer des traces dans le format Pajé). En plus de la reproduction graphique des données d exécution, chaque état du programme est établi avec sa propre couleur permettant ainsi à l utilisateur de trouver rapidement les goulots d étranglement, les états et les phases de repos qui peuvent être optimisés. Par ailleurs, ViTE assure l obtention rapide du rendu graphique. Et ce grâce à la bibliothèque OpenGL qui exploite l accélération du matériel graphique. L utilisateur peut ainsi explorer d énormes traces en très peu de temps. Tous les modules de ViTE sont écrits en C++. ViTE est supporté par plusieurs systèmes d exploitation tels que GNU / Linux, MacOS X ainsi que Windows et est aujourd hui à sa version Formats de traces supportés ViTE supporte trois formats de fichiers principaux : OTF, TAU et Pajé OTF Le format OTF ( Open Trace Format ) a été développé par TU Dresden. Il s agit d un format libre créé et utilisé par VampirTrace. Pourtant,ViTE ne peut pas supporter certaines caractéristiques du format OTF. Il supporte uniquement les états et les communications alors que certaines fonctionnalités restent manquantes. ViTE permet aussi de générer des 3

9 couleurs aléatoires pour le format OTF la première fois que l utilisateur ouvre un fichier, car ils ne sont pas stockés dans le fichier lui-même. L utilisateur peut ensuite modifier les paramètres pour adapter les couleurs à ses choix TAU Le format TAU est le format de traces le plus récent ajouté au projet ViTE. Bien que quelques fonctionnalités n ont pas été complètement testées et débuggées, certaines caractéristiques de base sont tout de même prises en charge tels que les états, les événements et les communications Pajé Le format de trace Pajé est le premier format pris en charge par ViTE. Il s agit d un format auto-interprété c est à dire qu il comprend en même temps la déclaration de chaque événement qui peut être considéré comme un tableau composé de plusieurs champs nommés, les états présents dans la trace ainsi que les communications entre ces états. ViTE supporte la plupart des fonctionnalités du format Pajé : les événements, les communications, les états, les variables et les couleurs des états... De ce fait, le format Pajé est considéré comme le format le plus adapté pour ViTE vu que la majorité des fonctionnalités est supportée. Figure 1.1 Exemple de trace d exécution visualisée sur ViTE 1.2 Visualisation des traces avec ViTE Une trace est un fichier formé d événements qui peuvent chacun être considéré comme un tableau composé de plusieurs champs qu on appelle les "tokens" et qui disposent d un nom, d un type et d une valeur. Elle est formée essentiellement d un conteneur racine qui va accueillir un ensemble de conteneurs secondaires. Ces conteneurs secondaires sont 4

10 représentés dans la figure ci-dessous par les lettres allant de «A» à «G». Un conteneur représente l état d un thread, processus, etc... Comme son nom l indique, chaque conteneur va contenir les états et les événements déclarés dans le fichier de trace et qui sont représentés dans la figure ci-dessous par les rectangles en bleu ciel : Figure 1.2 Représentation simplifiée d une trace d exécution Comme évoqué précédemment, ViTE permet de visualiser des traces d exécution sous différents formats. Pour ce faire, il établit des interactions entre trois modules principaux pour donner le rendu correspondant. Ces trois modules sont le Parser, le Render et l Interface comme l indique la Figure 1.3. Figure 1.3 Interactions entre les différents modules de ViTE 5

11 1.2.1 Le Parser Le Parser ou analyseur est le module permettant d analyser le fichier de trace fourni ligne par ligne en segmentant le flux de caractères en entités élémentaires suivant un motif prédéfini dans le format que nous manipulons. De ce fait, le Parser est le module permettant de vérifier l existence et la cohérence des données présentes dans le fichier de trace et de manipuler les flux de ces données. Étant donné une entité, le Parser a pour but d envoyer les valeurs de cette entité à la structure de données correspondante pour les stocker. Le Parser lit donc un fichier de trace et envoie des messages à des instances de la classe «Trace» pour créer un rendu graphique. open the t r a c e f i l e ; I n s t a n c i a t e a ParserEventDecoder ; I n s t a n c i a t e a P a r s e r D e f i n i t i o n D e c o d e r ; while (! end_of_file ) { read the next e n t i t y ; try to r e c o g n i z e the e n t i t y type ; i f ( e n t i t y type i s a c c e p t a b l e ) { l i n k i t to the c u r r e n t e n t i t y ; c o n s i d e r i t as the c u r r e n t e n t i t y ; } } i f ( end_of_file ) { c l o s e the c u r r e n t element ; } Figure 1.4 Algorithme du Parser La Figure 1.5 illustre les interactions du Parser avec les différentes classes de ViTE. En déterminant le type de trace à l aide du Parser Factory, le parser instancie un ParserEvent- Decoder et un ParserDefinitionDecoder qui vont décoder les événements et les définitions composant le fichier de trace en question. 6

12 Figure 1.5 Les différentes interactions du parser Il est à noter que pour que le parsing soit possible, il faut que les informations présentes dans le fichier de trace soient valides, c est à dire que la syntaxe soit correcte au sens «reconnue et prévue» par le parser, sinon celui-là retournera des erreurs. Par ailleurs, en plus d être syntaxiquement correct, un Parser exige que la trace soit écrite selon un modèle prédéfini qui lui informe de ce qu il doit trouver : l ordre des informations, la nature des éléments introduits, le minimum d éléments qui doivent exister, les valeurs possibles de ces éléments Le Render Le Render ou Rendu est le module en charge de préparer et de fournir la représentation graphique des fichiers de trace. ViTE utilise la bibliothèque Qt pour sa fenêtre graphique et la bibliothèque OpenGL (Open Graphics Library) pour le rendu graphique des traces. Pour améliorer les performances de ViTE, les fonctions graphiques sont appelées par la structure 7

13 de données en parcourant l arborescence de la trace. Une autre caractéristique de ViTE consiste à permettre à l utilisateur de se déplacer librement dans le rendu graphique de la trace d exécution par l intermédiaire de deux primitives qui permettent un tel déplacement dans la trace : le défilement ou scrolling et la mise à l échelle ou scaling : Le défilement permet à l utilisateur de déplacer l image vers la gauche, la droite, le haut ou le fond dans la zone du rendu. La mise à l échelle permet à l utilisateur de redimensionner l image et d effectuer un zoom avant ou arrière sur zone particulière L interface Les différents modules de ViTE comme le Parser et le rendu graphique doivent disposer d un moyen simple d afficher un message que ce soit dans le terminal du système ou dans une fenêtre graphique. Une classe «Message» développée, ayant pour but de fournir un outil facile à utiliser pour afficher un message à l utilisateur n importe où dans le code source de ViTE. La classe Interface est la classe la plus critique du logiciel. Elle gère et connecte tous les modules de l application : à titre indicatif, elle analyse la ligne de commande, lance l interface de la fenêtre, crée un Parser et déclenche le remplissage de la structure de données. En outre, elle est utilisée pour diffuser des messages entre le rendu de la trace (OpenGL) et l interface graphique (Qt). 8

14 Chapitre 2 Le projet Étant l une des formes les plus répandues de suivi d exécution des applications, les traces nécessitent des outils de visualisation pour pouvoir les analyser et les interpréter graphiquement. Or, les performances de ces outils peuvent varier en fonction des caractéristiques des fichiers de traces : taille, emplacement, contenu, structure,... ce qui met en évidence des limites fonctionnelles pour les outils de visualisation des traces d exécution et pour ViTE en particulier. Dans ce chapitre, nous citons quelques limites qui ont représenté la problématique de notre projet et ce que nous avons présenté comme solution pour faire face à ces problèmes. 2.1 Motivation Bien que ce qu offre le Parser Pajé dans ViTE est plutôt satisfaisant, certaines limites proviennent du fait que les données relatives à la trace visualisée doivent se trouver en entier dans un même fichier, ce qui durcit éventuellement la tâche d analyse contextuelle des traces. D où l intérêt de modifier la façon avec laquelle le Parser les interprète et les analyse. La Figure 2.1 représente un schéma simplifié d une trace en format Pajé. Nous pouvons remarquer qu elle présente une suite régulière d événements qui peuvent se répéter à des instants différents. Figure 2.1 Schéma simplifié d une trace en format Pajé Ces suites peuvent être structurées en entités ou autrement dit en «patterns» auxquelles nous faisons appel en fonction de notre besoin tout en évitant de surcharger la trace. 9

15 Après avoir défini cette nouvelle structure, nous remarquons qu une reproduction temporelle répétitive de patterns surcharge la fenêtre de visualisation de la trace et n offre qu une vision très étroite du comportement de l application analysée. Pour cela, cette reproduction peut être négligée ou mise en valeur proportionnellement au niveau de précision exigé par l utilisateur. 2.2 Travail à effectuer Ce que nous proposons en tant que solution aux problèmes de multi-parsing consiste dans une première étape à modifier le Parser du format Pajé dans ViTE pour qu il soit capable d analyser de grandes quantités de données de traces d exécution qui proviennent de différentes sources et générer par la suite, la représentation graphique associée. Les travaux de recherche récents portant sur EZTrace nécessitent de générer des traces d exécution dans un nouveau format de fichier (Pajé2) dérivé du format Pajé. Ce nouveau format peut être considéré comme une version améliorée du format Pajé supportant des nouvelles structures «les patterns d événements». Pour mieux comprendre ce concept, la Figure 2.2 représente un schéma simplifié de la même trace présentée par la Figure 2.1. Figure 2.2 Schéma simplifié d une trace en format Pajé 2 L ensemble des événements "event_a" et "event_b" ont été regroupés dans la structure du pattern_1. Au niveau du format Pajé 2, seuls les temps d exécution des différents événements constituant le pattern_1 seront reproduits. Il n est donc plus nécessaire de reprendre tous les détails des événements qui se répètent au cours du temps. EZTrace est d ors et déjà capable de générer des traces en utilisant ce format de fichier, mais ViTE ne peut pas les afficher. C est là où se situe notre projet de fin d études : il s agit 10

16 donc d étendre ViTE pour pouvoir supporter le nouveau format de fichier : Pajé2. Finalement, nous désirons modifier la façon avec laquelle réagit la représentation graphique des patterns présents dans la trace visualisée au niveau d agrandissement, en créant une dépendance entre la précision des valeurs affichées et le niveau d agrandissement demandé pour éviter de surcharger la fenêtre de visualisation. Toutes ces modifications permettent de réduire la consommation en mémoire RAM et d accélérer le chargement des traces. Cela nous mène donc à pouvoir afficher des traces beaucoup grandes en un temps plus faible. 11

17 Chapitre 3 Déroulement du projet Dans ce chapitre, nous discuterons des différentes tâches réalisées au sein de ce projet et nous détaillerons les phases d implémentation des différents modules tout en justifiant les choix retenus. Nous passerons par la suite à une présentation des difficultés rencontrées. Les travaux menés dans le cadre de ce projet ont porté essentiellement sur le format Pajé et sur l adaptation de l implémentation de son Parser dans ViTE aux exigences du format Pajé2. Généralement, le Parser Pajé admet deux grandes familles de composants : Les définitions d événements : ce sont des lignes commençant par «%» et qui sont contenues entre «%EventDef» et «%EndEventDef». Ces définitions annoncent les caractéristiques, appelées également «tokens», des différents événements qui seront utilisés dans la deuxième partie du fichier de trace. Parmi ces caractéristiques, pour chaque définition d un événement, on associe un identifiant que nous utiliserons comme référence à la définition correspondante. Par la suite, une définition d un événement dans le format Pajé est de la forme suivante : %EventDef PajeDefineEntityValue 5 % Type string % Name string % Color color % Alias string %EndEventDef L exemple ci-dessus illustre une description de l évènement «PajeDefineEntityValue», disposant de quatre champs qui vont être utilisés pour accueillir les tokens correspondants. Les événements : une ligne d événement commence impérativement par l identifiant qui lui a été associé dans sa définition au niveau de la première partie du fichier de trace, suivi des différents «tokens» séparés par des espaces dans le but d assurer la correspondance entre les valeurs d une ligne d événement et les champs qui figurent 12

18 dans sa définition. L exemple ci-dessous illustre un appel de l événement 5 ainsi que les différents tokens qui le composent. 5 "ST_Thread" "Sending" " " "STV_MPI_Send" "ST_Thread" correspond au Type, "Sending" à Name, " " à Color et "STV_MPI_Send" à Alias. En résumant, un fichier au format Pajé contient impérativement deux parties : une première où nous retrouvons les définitions des événements et une autre dans laquelle nous explicitons les événements générés par l exécution de l application analysée. Ces deux parties seront analysées par le ParserPajé implémenté dans ViTE. Dès qu un Parser de type Pajé est crée, ce dernier instancie deux entités : - une PajeLine : formée essentiellement de pointeurs, une PajéLine est la structure dans laquelle nous stockons la ligne courante. Les pointeurs qui la composent sont de 3 types : 1) _id : qui contiendra la numéro de ligne dans le fichier 2) _nbtks : qui renseigne sur le nombre de tokens présents sur la ligne 3) tout un ensemble de pointeurs vers les différents tokens de la ligne traitée. Ainsi, une PajéLine est structurée comme le montre la Figure 3.1 : Figure 3.1 Structure d une PajéLine - une Trace : après avoir déterminé les types et les valeurs respectives des tokens présents sur une PajéLine, ces données seront rangées selon leur nature dans les différentes structures de l instance Trace. Figure 3.2 Structure d une Trace 13

19 Le remplissage des structures de la trace commence par un test de la valeur du premier token de la ligne Pajé stockée : - si ce token correspond au caractère «%» : nous en déduisons qu il s agit d une définition. Le Parser utilise ainsi le DefinitionDecoder et plus particulièrement la méthode «store_definition» pour ajouter ces informations à la trace. - sinon, le Parser Pajé déduit que c est un événement et fait appel à la méthode «store_event» de l EventDecoder. En résumé, un Parser Pajé fonctionne comme le montre la Figure 3.3 : Figure 3.3 Fonctionnement du ParserPajé 3.1 Le format Pajé2 Le format Pajé2 est une version modifiée du format Pajé. Pajé2 propose d améliorer la lisibilité des traces lourdes qui peuvent s étaler sur des milliers de lignes en introduisant un mécanisme de subdivision qui permet de répartir le contenu d une même trace sur différents fichiers. Pajé2, assurant ainsi une lisibilité meilleure par rapport à Pajé, permet encore de réduire la taille des traces, de les afficher plus rapidement et de réduire la consommation mémoire Outre la subdivision des fichiers de traces, Pajé2 continue à supporter les différentes structures de l ancien format Pajé que nous avons détaillées, et introduit en plus une nouvelle structurée appelée «Patterns». Un pattern est une suite d événements qui se produit dans un fichier de trace à des intervalles de temps qui ne sont pas nécessairement égaux. Par exemple, dans la Figure 3.4, la suite d événements 10, 11, 12, 10 se retrouve à plusieurs endroits à des instants différents. La présence de ce pattern est signalée par 14

20 un événement d identifiant 62. De la même façon, la fin de la définition d un pattern est marquée par la présence d un événement ayant comme l identifiant 63. Dans la Figure 3.5, on définit le pattern_4 comme étant la suite d événements 10, 11, 12, 10. Une fois un pattern devient reconnu par le Parser Pajé, il peut être utilisé par l intermédiaire de deux autres événements d identifiants 60 et 61 comme le montre la Figure 3.6. L exemple ci-dessous propose le même contenu d une trace d exécution en format Pajé puis en format Pajé2 : Format Pajé : Fichier : eztrace_output.trace Figure 3.4 Exemple de trace au format Pajé La trace en format Pajé, montre que la suite composée des événements 10,11,12,10 se produit à différents instants de la trace en changeant que les timestamps de ces événements. Format Pajé 2 : Fichier : eztrace_output_p#0_t# ept_pattern_4.ept Figure 3.5 Exemple de définition d un pattern en Pajé 2 Avec le format Pajé2, nous serons en mesure de créer un «pattern» à partir de la suite d événements 10,11,12,10, ce que montre le fichier : 15

21 «eztrace_output_p#0_t# ept_pattern_4.ept». Puis, nous modifions le «fichier racine» et introduisons le mot clé «Include» qui permettra non seulement d injecter le pattern mais encore de migrer sa définition du fichier de trace vers un autre sans altérer la cohérence des données présentées. Fichier : eztrace_output.trace Figure 3.6 Exemple d appel de Pattern en Pajé 2 Ainsi, nous pouvons affirmer qu un pattern possède les caractéristiques suivantes : Un Pattern peut se reproduire N fois dans une même trace. Un Pattern peut commencer et prendre fin irrégulièrement dans le temps. Un Pattern peut s étaler sur différentes durées. Un Pattern peut appartenir à différents containers. Un Pattern peut être composé d événements qui se produisent dans différents containers. Si nous regardons d avantage la définition du pattern_4, nous remarquons bien qu elle propose un ensemble de valeurs temporelles pour chaque événement. Ces valeurs, que appelons «valeurs exactes» par opposition aux «valeurs moyennes» qui figurent dans la partie déclarative, sont associées chacune à une occurrence de ce pattern dans la trace. Ces lignes servent à représenter les différentes occurrences du pattern avec les événements 60 et 61 dans la trace en se basant sur le token «key» qui figure tout au début de chaque ligne. 3.2 Gestion du multi-parsing Vu la façon avec laquelle le Parser Pajé a été conçu, ce module était incapable de manipuler plus qu un fichier à la fois, ce qui représentait notre première tâche. Pour pouvoir manipuler plusieurs fichiers à la fois, il suffit d ajouter une clause «% Include» contenant le nom du deuxième fichier à analyser comme suit : % Include "nom_fichier.ept" 16

22 Cela permet de stocker tous les événements d un container dans un fichier qui lui est propre. Nous amenons, dans une deuxième étape, le Parser Pajé à reconnaître le token «Include» et ce en ajoutant simplement une condition au moment de la détermination du type de la ligne en question. Enfin, il faut s assurer que si un sous fichier contient lui même un autre sous fichier, le même traitement sera appliqué. L algorithme que nous avons adopté est le suivant : parse ( char filename, bool f i n i s h _ t r a c e _ a f t e r _ p a r s i n g ) { while (! end_of_file ) { l i n e = c u r r e n t l i n e i f (1 s t token == % ) { i f ( 2nd token == Include ) { // a new f i l e needs to be parsed filename_2 = name o f the new f i l e ; parse ( filename_2, f a l s e ) ; } e l s e { // i t s a d e f i n i t i o n s t o r e _ d e f i n i t i o n ( l i n e ) ; } } e l s e { // i t s an event store_event ( l i n e ) ; } read the next l i n e ; } } Par conséquent, le ParserPajé modifié est maintenant capable : 1- d analyser des traces qui sont subdivisées et/ou réparties sur plusieurs fichiers. 2- d analyser des traces contenant des clauses pointant vers d autres fichiers qui peuvent pointer eux même vers d autres fichiers. 3- de créer un seul rendu graphique pour toutes les données qui se trouvent réparties. Le fonctionnement du Parser Pajé dans ViTE après les modifications qui ont eu lieu est illustré dans la Figure 3.7 : 17

23 Figure 3.7 Fonctionnement du ParserPajé modifié 3.3 Support des Patterns Dans cette deuxième tâche, nous avons eu besoin de déterminer tout d abord l approche à adopter pour définir les traitements qui seront menés par le Parser face à un pattern. A ce niveau, deux choix se sont présentés : soit nous modifions la façon avec laquelle le Parser Pajé agit à la rencontre d un pattern lors de l analyse d un fichier de trace au niveau de la méthode «parse». soit nous faisons migrer tous les traitements de sauvegarde et d extraction relatifs à un pattern rencontré vers la classe ParserEventPajé. Nous avons retenu la deuxième approche vu que la modification de la façon avec laquelle le Parser Pajé analyse un fichier de trace risque de le déséquilibrer et d endommager les 18

24 procédures d analyse qu il adopte. Par conséquent, l ajout de cette nouvelle entité dans ViTE a été réalisé sur quatre étapes : 1- Création d une structure qui servira au stockage des patterns retrouvés dans les traces : Figure 3.8 Structure d un Pattern 2- Modification de la classe ParserEventPajé : la classe ParserEventPajé a été formée essentiellement de la méthode «store_event» que nous appelons depuis le ParserPajé pour stocker les événements dans la structure Trace. Vu que la présence d un pattern dans une trace est marquée par un événement ( à savoir un événement d identifiant 62 ), nous pouvons utiliser cette même méthode afin d analyser les différents événements constituant les patterns. 3- Définition des structures de sauvegarde d informations analysées : _Patterns : une map qui va contenir les définitions de tous les patterns trouvés dans la trace. std::map<std::string,pattern> _Patterns; _Occurences : une multi-map contenant les occurrences que nous faisons correspondre à leurs patterns respectifs. std::multimap<std::string,pajeline> _Occurrences; La Figure 3.9 montre que la map _Patterns chargée d accueillir les différents patterns de la trace, enchaîne une nouvelle entité de cette structure à celles déjà présentes. Le Parser intervient ainsi pour remplir la liste d événements composant le pattern et s arrête à la rencontre de l évènement 63. Le Parser Pajé se retrouve, ensuite, dans la deuxième partie du fichier de définition du pattern et procède alors à la sauvegarde des temps d exécution exacts dans la map _Occurrences, ce qui est illustré par la figure

25 Figure 3.9 Instanciation et sauvegarde d un pattern Figure 3.10 Sauvegarde des occurrences du pattern 20

26 4- ajout de quatre nouveaux événements : Ceci revient à définir les quatre événements évoqués précédemment dans les structures dédiées aux définitions dans la classe PajeDefintion pour qu ils soient identifiables par le Parser Pajé lors du parsing. Le tableau ci-dessous résume les 4 nouveaux événements servant à la manipulation de la structure Pattern et de ses attributs : EventID Nom de l événement Fonction 62 _PajeDefinePattern -Créer un pattern -Remplir sa suite d événements 63 _PajeEndDefPattern -Remplir une map d occurrences 60 _PajeStartPattern -Sélectionner le pattern à utiliser 61 _PajeEndPattern -Sélectionner l occurrence du pattern -Ajouter le pattern avec l occurrence correspondante à la trace Par la suite, le Parser Pajé réagit comme suit face à un Pattern : switch ( eventid ) { case _PajeDefinePattern : { c r e a t e a new pattern i n s t a n c e ; f i l l the pattern s events l i s t ; } c a s e _PajeEndDefPattern : { f i l l the occurrences map ; } case _PajeStartPattern : { get the pattern s name ; p a t t e r n _ s e l e c=s e l e c t the pattern from the map ; } case _PajeEndPattern : { get the occurrence s key ; store_pattern ( p a t t e r n _ s e l e c ) ; } d e f a u l t : parse_event ( l i n e ) ; } 21

27 3.4 Optimisations de ViTE Après avoir introduit la notion de pattern dans ViTE et une fois que le Parser Pajé arrive à l identifier, nous avons commencé par l introduction d une procédure de parsing restreinte aux valeurs moyennes. Pour cela, nous calculons la proportion de chaque événenemnt du pattern par rapport à la durée moyenne du pattern qui correspond à la durée de l occurence 0. Puis, nous représentons les différents événements du pattern en tenant compte des proportions calculées. Par exemple, considérons la Figure 3.11, l événement 40 représente 35% de la durée moyenne du pattern. Nous représentons ce même événement et avec les mêmes proportions pour toutes les autres occurrences du pattern présentes dans la trace. Figure 3.11 Parsing avec les valeurs moyennes Puis, nous avons pu mener le Parser à utiliser les timestamps exacts pour chaque occurrence à part. Cependant, nous avons remarqué qu une utilisation excessive de patterns dans une même trace, peut encombrer l espace graphique, surcharger la fenêtre de visualisation et cacher certains détails. C est pour cette raison que nous proposons de rendre la trace affichée plus interactive en créant un lien entre le niveau de précision demandé par l utilisateur et ce que ViTE lui affiche en tant que rendu graphique. Les modifications apportées seront alors implémentées dans le module du Render qui prend la décision de : 22

28 créer le rendu graphique avec les valeurs moyennes des temps d exécution présentes dans les patterns si le niveau de précision exigé par l utilisateur est inférieur à un seuil prédéfini. Ou créer le rendu graphique avec les valeurs exactes, et mener par la suite un traitement supplémentaire dans le but de répondre aux exigences en précision. La première étape consistait alors à créer un flag «_use_exact_values» qui indique au Parser quel traitement à exécuter. Ce flag est positionné à «False» par défaut, ce qui fait que ViTE affichera les valeurs moyennes des temps d exécution des patterns que lorsque le niveau de zoom dépasse un certain seuil de précision, qui est calculé proportionnellement à la largeur de la zone sélectionnée par l utilisateur qu il désire agrandir. À la détection du dépassement du seuil, nous positionnons le flag à «True» ce qui envoie un signal de «re-parse» avec les valeurs exactes au Parser Pajé. De la même façon, une valeur d un zoom arrière allant au dessous de ce même seuil déclenche la procédure inverse, demandant au Parser Pajé de re-parser la trace avec les valeurs moyennes. Figure 3.12 Interactions Parser Render 23

29 3.5 Difficultés rencontrées Après avoir introduit les modifications citées ci-dessus, les tests que nous avons effectués ont révélé l existence de quelques bugs à l exécution. Le premier étant au niveau de la définition d un pattern qui accepte les PajéLines : - de définition des événements contenus dans le pattern - vides - contenant des événements 60 ou 61 d autres patterns à condition qu ils soient déclarés plus haut Or si la ligne contient une référence vers un autre fichier de trace qui doit être traité, le Parser n arrive pas à la traiter vu la façon avec laquelle nous avons prévu la création d un pattern, comme le montre l exemple suivant : D autre part, la modification du Render cause un dysfonctionnement du zoom de temps en temps, qui ignore ainsi les clics de l utilisateur et finit par rendre des vues aléatoires. Un "reload" de la vue résout provisoirement le problème. 24