Pour ´evaluer le passage `a l’´echelle et les performances du prototype impl´ement´e, diff´erents ensembles de donn´ees synth´etiques ont ´et´e exp´eriment´es en utilisant le le syst`eme PCIA. Les exp´erimentations men´ees visent `a montrer l’efficacit´e et l’impor- tance des patterns de migration identifi´es. Les ´etapes du protocole exp´erimental sont les suivantes : (i) dans un premier temps, nous avons g´en´er´e des ensembles de donn´ees de diff´erentes tailles pour servir de jeu de test de l’exp´erimentation. (ii) ensuite, nous avons calcul´e et compar´e le temps de migration pour chaque pattern et chaque en- semble de donn´ees. (iii) et en fin, nous avons ´evalu´e le temps et les taux de migration des instances et nous avons analys´e les corr´elations entre les ´el´ements du syst`eme.
7.4.1
Pr´eparation des donn´ees d’exp´erimentation
Pour la g´en´eration des donn´ees d’exp´erimentation, nous avons proc´ed´e `a la simula- tion des ex´ecutions du protocole Retraite de la figure5.1. Quatre ensembles de donn´ees (data-sets : DS) synth´etiques contenant, respectivement, DS1 = 1.000, DS2 = 10.000, DS3 = 100.000 et DS4 = 1.000.000 instances ont ´et´e g´en´er´ees de mani`ere al´eatoire et leurs traces d’ex´ecution sont sauvegard´ees dans la base de donn´ees des Instances , d´ecrite dans la section 7.2.2 (table. 7.1).
Comme illustr´e dans la figure 7.7, il est observ´e que le temps de g´en´eration suit une ´evolution croissante en fonction du nombre d’instances `a g´en´erer. Ce temps atteint 1060 secondes pour l’ensemble de donn´ees le plus large DS4 (' 17 minutes).
Une fois les instances sont g´en´er´ees et sauvegard´ees, uniquement celles qui sont `
a l’´etat actives seront filtr´ees pour le processus d’exp´erimentation, car les instances termin´ees sont sans aucun int´erˆet dans notre contexte de migration d’instances actives.
CHAPITRE 7. IMPL´EMENTATION ET EXP ´ERIMENTATION
Figure 7.7 – Evolution du temps de g´en´eration des donn´ees d’exp´erimentation
Afin de s’assurer de la consistance du nombre d’instances actives et de la repr´e- sentativit´e des ´echantillons de test, nous avons calculer les taux des instances actives par rapport au nombre total des instances g´en´er´ees.
La figure 7.8 montre que ce taux est l´eg`erement sup´erieur `a 88 % pour l’ensemble des ´echantillons manipul´es et qu’il suit une croissance non lin´eaire, `a cause de la fonction al´eatoire de g´en´eration des instances. N´eanmoins, ce taux est largement sa- tisfaisant pour mener les analyses de l’impact lors de la migration des instances actives.
Figure 7.8 – Variation des taux des instances actives
7.4.2
Tests de passage `a l’´echelle
Pour examiner le passage `a l’´echelle du prototype r´ealis´e, une premi`ere exp´erimen- tation a ´et´e conduite en exploitant le pattern de migration Strict (PM1 ; voir section
6.3.1). Dans cette perspective, le temps n´ecessaire, pour accomplir la migration des diff´erents lots d’instances conform´ement `a ce pattern, a ´et´e calcul´e et analys´e.
La figure 7.9 illustre la variation du temps de migration pour le pattern Strict. Il est observ´e que ce temps croit exponentiellement en fonction du volume d’instances `a
CHAPITRE 7. IMPL´EMENTATION ET EXP ´ERIMENTATION
Figure 7.9 – Variation du temps de migration pour le pattern Strict PM1
faire migrer de l’ancienne version du protocole Retraite vers sa nouvelle version. Comme le processus de migration doit ˆetre op´er´e (off-line), les r´esultats obtenus sont encourageants (4036 secondes ' 1 heure pour faire migrer un million d’instances du lot DS4). Cette observation motive l’exploitation du syst`eme pour la prise en charge des applications grand-public.
Dans une deuxi`eme exp´erience, le temps n´ecessaires pour faire migrer les instances actives, conform´ement aux diff´erents patterns de migration, a ´et´e ´etudi´e. Cette ex- p´erience vise `a comparer l’ordre de grandeur du temps de migration pour les dif- f´erents patterns. Pour cela, un ensemble de donn´ees de grande taille a ´et´e choisi (DS3 = 100.000 instances), puis nous avons fait varier les patterns de migration d’obli- gations historiques (PM1,. . . , PM5), tout en calculant le temps de migration pour chaque lot et chaque pattern.
Figure 7.10 – Temps de migration du lot DS3 (100.000) pour les diff´erents patterns
Le graphe de la figure 7.10 montre que ce temps varie de 603 secondes pour le pattern (Strict) et descend jusqu’`a 112 secondes pour le pattern (R´eduction PM4). Pour les autres patterns, le temps de migration est du mˆeme ordre de grandeur (entre 200 et 400 secondes, voir zone ombr´ee). Ces r´esultats sont justifi´es par le fait que pour
CHAPITRE 7. IMPL´EMENTATION ET EXP ´ERIMENTATION
le pattern (Strict), une comparaison exacte est faite pour chercher la trace t´emoin d’une instance active. La mise en œuvre de ce pattern exige une copie en bloc de la table Instances de l’ancien protocole vers la table Instances du nouveau protocole, telle que expliqu´e dans la section 7.2.2. Cette op´eration engendre un temps de traitement consid´erable. Cependant, pour le dernier pattern (R´eduction PM4), une sous-trace est, tout simplement, supprim´ee de la trace de l’instance `a faire migrer.
7.4.3
Evaluation des performances du syst`´
eme
Pour ´evaluer les performances du prototype PCIA, nous avons calculer le temps total de migration des quatre ensembles de donn´ees de test, et ce conform´ement aux cinq patterns d’obligations historiques (PM1,. . . , PM5).
Figure 7.11 – Analyse du temps de migration pour les divers patterns
Les r´esultats expos´es dans la figure 7.11, montrent que le temps global de migra- tion varie de quelques secondes `a quelques minutes, quant la taille des donn´ees de test augmente jusqu’`a 100.000 instances DS3. Pour l’´echantillon le plus volumineux DS4 contenant 1.000.000 instances, le temps de migration le plus mauvais (de l’ordre de 1h30 ) est observ´e pour le pattern Strict (PM1). Ce dernier exige des parcours ex- haustifs et des comparaisons exactes entre les diff´erents chemins des deux protocoles. Le pattern R´e-ordonnancement d’activit´es (PM2) vient en seconde position en termes de temps de migration. Cette observation est justifi´ee par la nature de ce pattern qui manipule l’op´erateur shuffle sur les s´equences d’activit´es. (calculer toutes les combi- naisons possibles et tester l’appartenance d’une trace `a cet ensemble). Pour les autres patterns, le temps d’ex´ecution n´ecessaire pour faire migrer 1.000.000 d’instances avoi- sine les 30 minutes, et il descend jusqu’`a 15 minutes pour le pattern Extension (PM5). Dans une derni`ere exp´erience, nous avons examin´e la pertinence des patterns pro- pos´es, en calculant les taux des instances migrables : (instances migrables/ instances candidates) pour chaque pattern et en fonction des ´echantillons de test. Cette exp´e- rience a ´et´e men´ee sous l’hypoth`ese qu’un taux de migration faible peut compromettre toute l’approche propos´ee. Les r´esultats obtenus, tels que illustr´es dans la figure 7.12, font ressortir que ce taux est autour de 80 % pour les trois patterns (PM1, PM2 et PM4) et il est presque `a 100 % pour les deux patterns restants (PM3 et PM5).
CHAPITRE 7. IMPL´EMENTATION ET EXP ´ERIMENTATION
Figure 7.12 – Comparaison des taux des instances migrables des diff´erents patterns
Les r´esultats obtenus sont tr`es prometteurs et consolident les sp´ecifications des patterns identifi´es dans notre approche. N´eanmoins, les techniques d’adaptateurs [143,
144, 145] demeurent incontournables pour faire migrer les instances restantes et qui ne peuvent ˆetre transf´er´ees par notre approche.