TG-LL
Méthode d’évaluation de performance pour système migré
État de l’art
Comme nous venons de voir dans le chapitre précédent, il existe bien des façons pour améliorer la performance d’uneapplication. Plusieurs chercheurs y travaillent sans cesse pour repousser les limites des systèmes.Certaines recherches traitent d’optimisation de composantes matérielles, qui introduisent la notion de traitement en parallèle au niveau du CPU [7]. D’autres recherches sont plus axées sur le comportement des instructions en mémoire [12], la génération du code machine, la compilation et la prédiction des instructions suivantes [20]. Certains chercheurs s’intéressent même à développer des outils pour aider les développeurs à l’optimisationde leur code . L’optimisationdes performances va même jusqu’àoptimiser le code au niveau du code machine.
Une grande partie des recherches effectuées sur l’amélioration des performances se concentrent sur la transformation du code lors de la compilation. Les compilateurs usuels ne font que transformer le code en langage machine. Comme cette étape est nécessaire pour pouvoir lancer les applications développées, des chercheurs y ont vu là une opportunité de transformer le code de manière performante et ensuite en langage machine.Il existe des méthodes qui aident à prédire les performances des nouveaux systèmes avant même que le processus de migration ne soit complété [22]. Ces méthodes ont aussi fait des sujets de recherches pour tenter d’êtreles plus précises possibles lors de ces prédictions [19].Dans ce chapitre, nous verrons différentes recherches effectuées sur la performance de code et quelques méthodes pour nous aider avec la performance.
Projet CAPS
L’équipe de chercheurs du projet CAPS (Compilation, architecture des processeurs superscalaires et spécialisés) [19] de l’universitéde Rennes dirigé par André Seznec se sont intéressés à quelques champs de recherche notamment l’architecture des processeurs, les interactions entre les compilateurs et l’architecture,ainsi que les compilateurs et les plateformes logicielles pour l’optimisation des performances.L’objectifde leurs recherches est d’aiderles usagers à utiliser le plein potentiel de leur machine tout en leur masquant la complexité des composantes matériels.
Un des volets de leurs recherches les a menés à développer un logiciel pour aider les développeurs à la dernière étape de la programmation, c’est-à-direl’optimisationdu code. Ils ont nommé cet outil CAHT (Computer Aided Hand Tuning) . Ce logiciel s’aidede l’intelligenceartificielle pour proposer du code optimal à la place du code existant en utilisant le principe de raisonnement par cas de base.Une autre section de leur projet cible la grosseur du code. Ils en sont venus à la conclusion que, pour avoir un bon compromis entre la grosseur du code et la performance, il fallait réduire le plus possible les lignes de code utilisées rarement et garder le gros du code dans les sections les plus souvent utilisées . Leur raisonnement est que le code souvent utilisé est chargé en mémoire et peut être utilisé plusieurs fois. Donc, le temps de chargement du code est effectué une fois et le temps d’exécutionest effectué autant de fois que nécessaire. Comme le temps de chargement du code en mémoire est le plus long, il est plus performant de privilégier le code pour les traitements utilisés souvent. En minimisant le code des traitements utilisés plus rarement, on évite de trop charger les données en mémoire et on sauve ainsi sur le temps de chargement.
Migration de code par transformation
Des chercheurs des universités de Waterloo, Victoria et Toronto ont quant à eux fait des recherches sur la migration par la transformation de code. Leur rapport de recherche fait état d’uneexpérience de développement d’unoutil de migration [21] . Cet outil rencontre des spécifications non-fonctionnelles et permet un processus de migration incrémentaI. Les spécifications non-fonctionnelles visées par l’outilsont que le code résultant de la migration soit au moins aussi performant que l’anciencode et que le code résultant soit facile à maintenir. Leurs recherches ont été faites avec un système légataire de moyenne envergure. La stratégie de migration qu’ilsont utilisée a été de la « traduction» de code car elle ne requiert pas un expert pour comprendre l’anciencode et parce que c’estune façon de faire qui est facilement automatisable. Le code de départ est du PL/IX (un dialecte du PL/I langage développé par IBM dans les années 1970) et il sera migré vers du C++.La migration de code à l’aide de leur outil passe par différentes étapes . Premièrement, les structures de données sont analysés au niveau du langage de départ et un équivalent est trouvé dans le langage cible. Comme toutes les structures de données d’un langage ne se retrouvent pas nécessairement dans un autre, il faut générer des artifices pour les simuler dans le nouveau langage. Pour faciliter la maintenance du code migré, la « traduction» du code se fait en gardant les structures d’algorithmes,les noms des variables, les commentaires et l’indentationdu code . Ainsi, le nouveau code ressemblera le plus possible à l’anciencode et un programmeur qui est habitué dans l’ancienlangage se retrouvera dans le nouveau.Comme ils développent un outil qui permet la migration incrémentale d’un système, ils ont dû se baser sur certains points pour bien choisir par quelles composantes du système il fallait commencer. Une analyse complète du système doit d’abordêtre faite pour identifier les composantes les plus importantes ainsi que les sous-systèmes et les interfaces correspondantes. Chaque composante est analysée pour en ressortir leurs interfaces avec le système, le nombre de données qu’elletraite, les algorithmes utilisés ainsi que les structures de données utilisées . Une fois l’analyse complétée, on peut choisir les candidats idéaux pour commencer la migration . On peut se baser sur la grosseur des composantes; Une petite composante sera facile à examiner et à comparer manuellement avec le code de départ. On peut également choisir une composante par rapport à son interface, plus l’interfaceest simple et avec le moins d’effets secondaires possibles, plus cette composante sera facile à migrer. Les composantes qui affectent la performance à cause d’un manque de ressource ou à cause qu’ellessont un goulot d’étranglementpeuvent aussi être choisies en premier.L’outilde migration du code va tout d’abordanalyser le code et le transformer en arbre syntaxique abstrait [21] . Un arbre syntaxique abstrait est un arbre dont les nœuds sont des opérations sur le code (exemple : ({ if») et les feuilles sont des variables (exemple : un integer) . (Voir un exemple en annexe 2) Ces arbres représentent bien tous les détails du code, ce qui facilitera la transformation de la migration. Des patrons sont alors identifiés dans l’ancienlangage et leurs équivalents sont trouvés dans le langage cible . Le patron cible est alors transformé en code selon une routine de transformation préétabli pour ce patron . Dans cette routine, les structures de données sont transformées dans leur équivalent ou bien dans un artifice qui simule cette même structure.Voici un exemple de migration de code avec leur outil de migration . L’exemple démontre une instruction ({ if». Le code de départ est du PL/IX qui sera transformé en C++.
If /lkill then cannot_kill = true;
L’arbresyntaxique est illustré à la figure 1 :
Le patron correspondant à cette expression est le suivant:
Statementlf
condition: Expression
then-clause: Statement
La routine de transformation est la suivante:
Transform Statement
.. Transform Statementlf
–> «if (»
…. Transform Expression
…… Transform LogicalNot
–> <<(1)>
…….. Transform IdentifierReference
–> «kill»
–>
–>
«»>
«»>
…. Transform Statement
…… Transform StatementAssignment
–>
–>
–> «cannoCkill = true;»
Ce qui donne comme code résultant en C++ :
if ( (lkill) ) {
cannot_kill = true; }
Une fois la composante migrée, il faut l’intégrerdans le système et supprimer l’ancienne.Il faut la compiler et corriger le code si nécessaire, il faut écrire des classes pour simuler l’anciensystème et il faut écrire une interface pour que la composante interagisse de la même façon que le faisait l’ancienne. Bien sûr, plus il y a de composantes migrées, moins il y aura d’interfaces à fa ire car des composantes différentes peuvent utiliser la même interface.
L’évaluationqu’ilsont faite sur leur outil de migration se base sur certains points dont voici ceux qui nous intéressent particulièrement . Ils vont vérifier les performances du nouveau code, ils vont comparer les performances de l’ancienet du nouveau code, puis finalement, ils vont regarder les efforts humains requis pour faire des corrections au code migré.
Le système légataire qu’ilstransforment est un système permettant de faire de l’optimisation de compilation (avec compilateur gcc). Pour pouvoir comparer le système non-migré avec le nouveau système (partiellement migré), ils ont décidé de lancer leurs mesures sur 4 sous système différents . Premièrement, ils ont mesuré une partie de leur système qui contient 13000 lignes de code. Ensuite, ils ont mesuré le module servant à faire de la compilation gcc, ils ont également prit des mesures sur leur librairie g++, puis ils ont mesuré un module distinct que leur système légataire utilise (JPEG) . Ils ont lancé leurs tests de mesures un certain nombre de fois et ont prit une moyenne des temps d’exécution. Ils ont par la suite migré les sous systèmes du système légataire et ont refait les mêmes tests avec le nouveau code, voici leurs résultats [21]:
Leur système a optimisé 4 différentes sources en C. On peut voir, qu’engénéral, le temps de traitement s’estamélioré, et ce, pour seulement 3 composantes migrées dans le système.
Leur outil de migration les a aidés à sauver du temps au niveau des ressources humaines nécessaires pour transformer les composantes. Par exemple, pour une composante qu’ilsont migré, si la migration se serait faite manuellement du début à la fin, elle aurait demandé 50 jours/personnes, ainsi qu’un 10 jours/personnes pour l’optimisation de cette dernière. À l’aide de leur outil, l’effort demandé est de 1 jour/personne pour faire l’adaptation de la migration. On peut donc dire que leur processus de migration permet de gagner énormément de temps.
Ils ont également comparé la grosseur des composantes avant et après la migration . Ils ont constaté qu’enmoyenne le code est 5% plus important une fois migré. Ceci est dû au fait qu’ila été nécessaire d’écrire des artifices pour simuler l’ancien comportement avec le nouveau code.
Si on revient sur leurs objectifs de recherche, on peut dire qu’ilsont atteints leur but qui était de développer un outil de migration de code qui rencontrerait des spécifications non-fonctionnelles. Ces spécifications étaient que le code résultant de la migration soit maintenable et au minimum aussi performant que l’anciencode.
Méthode d’évaluation de performance pour système migré
Des chercheurs de l’Universitéd’Hamiltonen Ontario se sont intéressés à une méthode d’évaluation de performance de systèmes migrés avant même que la migration soit terminée . Ils ont étudié la méthode CAPPLES (CApacity Planning and Performance analysis method for the migration of LEgacy System [22]) et en sont venu à la conclusion que cette méthode avait des limitations. Ils ont donc proposé une deuxième méthode d’évaluation de la performance pour combler les manques de la méthode précédente : PELE (Performance Evaluation method for LEgacy system [22]). Pour bien comprendre leur recherche, regardons d’abordla méthode CAPPLES.
CAPPLES
Étape 1: Spécification de la fenêtre de mesure d’activité. Cette fenêtre de mesure correspond au temps où le système est utilisé, comme par exemple, de 8h à 17h du lundi au vendredi.
Étape 2 : Mesurer le système légataire et les spécifications de la fenêtre de mesure. Dans cette étape, des outils surveillent et compilent l’activité du système légataire pendant sa fenêtre d’activité. Les transactions demandées au système sont comptabilisées en nombre de transactions/heure . Ceci nous permettra de trouver le moment de la journée où le système est le plus sollicité .
Étape 3 : Identification des services concernés dans le système légataire. Ici, on identifie les services qui sont associés aux transactions les plus demandées lorsque le système est le plus sollicité. (Transactions trouvées à l’étape2)
Étape 4: Faire le lien des services concernés du système légataire avec le système cible. Chaque service du système légataire doit être offert dans le système cible . Donc, il faut faire un lien entre les transactions du système légataire et les transactions du système cible. Dû au manque de documentation, les transactions sont difficilement identifiables dans le système légataire, elles seront donc liées entre-elles en passant par des services. Ceci est possible car les services ont un grand degré d’abstraction par rapport aux transactions, ce principe est illustré dans la figure 2 [22] :
Étape 5 : Génération d’unecharge de travail synthétique dans le système cible. Bien que des mesures aient déjà été prises dans les étapes 2 et 3, on complète ici la prise de mesure de toutes les activités qui surviennent dans le système cible. On établi ainsi la charge de travail du nouveau système .
Étape 6: Modélisation du système cible. Cette étape sert à modéliser le plus fidèlement possible ce à quoi le système cible ressemblera. Toutes les activités trouvées dans les étapes précédentes doivent y être incluses. Il ne faut pas s’arrêter aux transactions du système uniquement, toutes les activités qui peuvent potentiellement affecter les transactions doivent être prises en compte.
Étape 7 : Calibration et validation du modèle du système cible. Le modèle de simulation du système cible créé à l’étapeprécédente est considéré valide si le temps de réponse de ces services est équivalent aux services du système cible. Le modèle du système doit être aussi complexe que le système cible et avoir une charge de travail équivalente pour avoir de bonnes mesures dans les étapes suivantes. Le modèle n’apar contre pas besoin d’êtreaussi grand que le système légataire.
Étape 8 : Prédiction de la charge de travail. Dans cette étape, la charge de travail synthétique établie à l’étape5 doit être réglée pour simuler le système cible lorsque tous les services du nouveau système seront en fonction.
Étape 9 : Prédiction des performances du système cible. Cette dernière étape consiste à prendre le modèle de simulation créé à l’étape6 et de lui appliquer la charge de travail prédite à l’étape8. On peut alors prédire le comportement du système cible.
Selon ces chercheurs, la méthode CAPPLES comporte trois limitations importantes.
Premièrement, il est nécessaire d’aller prendre des mesures dans l’environnementcible pour bien établir la charge de travail à l’étape5. Cela veut dire que l’environnement cible doit déjà être développé. Il serait préférable de faire la mesure sur le système légataire et de faire le lien sur le système cible. Ceci nous permettrait de prédire la mesure sans que le système cible ne soit prêt .
Deuxièmement, cette méthode ne modélise pas le système légataire. Un modèle du système à migrer pourrait grandement aider lors de l’étape de la validation du système cible. Ceci permettrait aussi de faire une comparaison des modèles entre l’ancienet le nouveau système . Dans la méthode CAPPLES, aucune comparaison n’est faite entre les systèmes.
Pour finir, la méthode utilise des modèles de simulation qui sont complexe à développer et qui demandent beaucoup de temps. Quand on a des échéanciers et des budgets à respecter, les modèles de simulation sont à éviter car ils demandent énormément de détails et ils sont coûteux à l’entreprise.
PELE
Voyons maintenant la méthode PELE [22] qui comporte 8 étapes.
Étape 1 : Détermination de la charge de travail de l’anciensystème. La charge de travail est regardée dans un intervalle de temps donné et le nombre de transactions y est répertorié. Cette charge de travail doit être également représentative au système cible.
Étape 2: Prise de mesure du système légataire. Il ya deux mesures importantes à prendre lors de cette étape: l’intensitéet la demande de ressource. L’intensitéest la charge appliquée au système, la demande de ressource est le temps que les services prennent pour effectuer une transaction.
Étape 3 : Identification des services concernés dans le système légataire. Cette étape est la même que la méthode CAPPLES.
Étape 4 : Création d’unmodèle pour le système légataire. À cette étape, on se sert d’un modèle de file d’attente pour créer un modèle de performance pour le système légataire. Le modèle de file d’attente ressemble simplement aux étapes que doit franchir une transaction pour s’effectuer. Le modèle de performance est alors utilisé pour trouver le temps d’exécution d’une transaction. Il sera alors validé en comparant le temps d’exécutiond’unetransaction dans le système légataire. Le modèle de performance est considéré acceptable si les temps de réponse ont une différence de moins de 20%.
Étape 5 : Répertorier les demandes de ressource pour paramétrer le modèle du système cible. Dans cette étape, on regarde les services que l’onveut avoir au niveau du système cible en se basant sur le système légataire . Par exemple, si on veut migrer une base de données sous format « fiat system» en un format relationnel, il faut prendre en considération cette nouvelle façon de faire pour paramétrer le modèle. Si la nouvelle base de données est opérationnelle sur le système cible, on peut s’en servir pour calculer les besoins en ressources. Sinon, ces besoins devront être estimés en se basant sur le système légataire .
Étape 6: Analyse et validation du modèle du système cible. Des techniques spécifiques sont utilisées pour trouver le temps de réponse d’uneopération à l’aidedu modèle bâti à l’étape précédente. Ensuite, on peut comparer ces temps avec le système cible si, bien sûr, il est fonctionnel.
Étape 7 : Comparaison des performances du système légataire et du système cible. Ici, on utilise le modèle du système légataire pour calculer le temps de réponse d’une opérationet on la compare avec le temps trouvé à l’étapeprécédente qui était basé sur le modèle du système cible . Les résultats attendus de cette comparaison devraient être meilleurs sur la cible.
Étape 8 : Prédiction de la charge de travail et de la performance du système cible. Cette étape est la même que les étapes 8 et 9 de la méthode CAPPLES.
Ce qui est bien dans cette méthode c’est que l’on peut l’adapter avec la condition du système cible. Si le système cible est fonctionnel, la méthode va valider ces évaluations de temps sur le système cible. Si le système cible n’estpas fonctionnel, la méthode se sert de modèles et d’évaluationde temps pour évaluer les performances.
La figure 3 présente des principales étapes de la méthode PELE si le système est fonctionnel [22] :
La figure 4 présente les principales étapes de la méthode PELE pour un système cible qui n’estpas fonctionnel [22] :
Figure 4 : Étapes de PELE pour un système cible non-opérationnel.
Maintenam: que nous venons ae vOir les aeux memoaes, regaraons comment la méthode PELE répond aux limitations de CAPPLES.
Dans CAPPLES, il est nécessaire d’aller prendre des mesures dans l’environnementcible pour établir la charge de travail. Avec PELE, le modèle du système légataire est utilisé pour prendre ces mesures. Donc, pas besoin du système cible.
Dans CAPPLES, aucune modélisation du système légataire n’était faite . Avec PELE, un modèle est fait pour le système légataire et cible. Cette méthode permet donc des comparaisons entre les systèmes .
CAPPLES utilise des modèles de simulations détaillés qui sont complexe à développer et qui demandent beaucoup de temps. Dans PELE, les modèles de simulations utilisés peuvent être simple, car les techniques utilisés pour évaluer les performances n’ontpas besoin de détails . Donc, on sauve du temps en utilisant la méthode PELE plutôt que CAPPLES.
Il faut cependant faire attention lors de l’utilisationde la méthode PELE car elle ne se base uniquement que sur le temps moyen des transactions évaluées. Elle ne permet pas d’identifierune dégradation de la performance à long terme causé, par exemple, par une fuite de mémoire . Cette méthode est par contre un bon début d’évaluation. Selon ces chercheurs, un bon complément à cette méthode serait de compléter son utilisation en ajoutant d’autresméthodes pour détecter des problèmes de performance à long terme.
Étude de cas
Les chercheurs [22] se sont intéressés à un cas de migration de version de MySQL pour valider leur méthode PELE. Ils ont fait la comparaison entre trois versions soit : MySQL 4.1.22, MySQL 5.0.90 et MySQL 55.5. Ils ont utilisé le logiciel « TPC Benchmark W )} (TPC-W) pour simuler des usagers qui naviguent sur leur application web et ainsi créer une certaine charge de travail. Ce logiciel peut être paramétré de différentes façons de manière à tester différents aspects du système. Comme par exemple, on peut paramétrer le temps entre les transactions ainsi que le nombre d’usagerset d’items présent dans la base de données. Le nombre d’usagersnaviguant sur le système sera fixe tout au long de leurs essais.
Pour faire leurs tests, ils se sont fait un environnement isolé sur un portable avec un serveur web et les 3 versions de MySQL à tester. Ainsi, aucun facteur externe ne peut venir influencer leurs résultats. Leur modèle du système est d’ailleursun réseau fermé contenant uniquement deux ressources : ressource disque et ressource CPU .
Pour commencer, le modèle du système est validé en développant un environnement expérimental en paramétrisant TPC-W avec 150 usagers, un temps entre les transactions à 0 et une base de données contenant 28800 clients et 1000 items. Avant de prendre les mesures qui serviront à comparer les différentes versions, ils laissent toujours à TPC-W 120 secondes pour que l’applicationne soit pas en mode « départ)} (c’est-à-dire que les temps de chargement en mémoire des principales transactions soient déjà effectués) ensuite les 600 secondes suivantes sont comptées .
La méthode PELE est alors appliquée comme suit :
– Ils exécutent TPC-W avec la version MySQL 4.1.22 pour avoir le temps moyen de réponse d’unetransaction et ils gardent l’utilisationdu disque et du CPU . (Tableau 2)
– Le modèle du système est utilisé pour calculer le temps de réponse à l’aidede technique « MVA )} (mean value analysis) . Le temps trouvé est comparé avec le temps mesuré précédemment . (Tableau 3)
|
Table des matières
Remerciements
Abstract
Résumé
Table des Matières
Liste des tableaux
Liste des figures
Chapitre 1 : Introduction
1.1 Techniques d’amélioration de performance
1.2 Optimisation de code
1.3 Optimisation extérieur au logiciel
1.4 Programmation orientée aspect
1.5 Optimisation à l’aide de la compilation
1.6 Conclusion
Chapitre 2 : État de l’art
2.1 Projet CAPS
2.2 Migration de code par transformation
2.3 Méthode d’évaluation de performance pour système migré
2.3 .1 CAPPLES
2.3.2 PELE
2.4 Étude de cas
2.5 Migration en service web
2.5.1 Explication par l’exemple
2.5 .2 Modèle de performance pour service web
2.6 Conclusion
Chapitre 3 : Mise en contexte
3.1 Projet Migration
3.1.1 Optimisations applicatives critiques
3.1.2 Performance matériel
3.1.3 Optimisation de la base de données
3.1.4 Tests de charge
3.1.5 Optimisations applicatives sur le traitement en lot
3.1.6 Quelques résultats
3.2 Conclusion
Chapitre 4 : Processus d’optimisation de performance
4.1 Définir des références
4.2 Collecte d’information
4.3 Analyse des résultats
4.4 Configuration
4.5 Tests et prise de mesures
4.6 Expérimentation
4.7 Analyse d’un traitement en lot qui génère un rapport
4.7.1 Collecte d’information
4.7.2 Analyse de résultat
4.7.3 Configuration
4.7.4 Test et prise de mesures
4.7.5 Analyse de résultat
4.7.6 Collecte d’information
4.7.7 Analyse des résultats
4.8 Conclusion
Chapitre 5 – Conslusion
Références
Annexe 1- Exemple de bytecode java
Annexe 2 – Exemple d’arbre syntaxique abstrait
Télécharger le rapport complet
