Analyse du temps de réponse dans une gestion complexe de

Afin d’évaluer les performances de l’approche de gestion complexe des services ainsi que les différents algorithmes, un ensemble de fichiers a été généré pour carac-tériser le comportement du système. Plus de 1000 fichiers comportant un graphe initial à transformer ont été générés avec un besoin aléatoirement défini (entrée·s et sortie·s aléatoirement définies parmi un ensemble de types possibles) ainsi qu’un nombre variable de services disponibles au moment de la génération du graphe (entrée·s et sortie·s aléatoirement définies également). De fait, potentiellement il est possible qu’il n’y ait aucune solution au besoin initial, et ce même une fois le graphe transformé. Les deux algorithmes d’exploration vont déterminer qu’il n’y a aucun plan d’exécution disponible à cet instant là. Dans le cas où un plan est disponible, l’algorithme glouton va retourner le premier plan qu’il trouve et l’al-gorithme optimisé va retourner le meilleur plan qu’il a trouvé. Dans le cas où un seul plan est possible les deux algorithmes vont trouver la même solution avec des temps de réponse différents : en effet, l’algorithme optimisé va prendre plus de temps à s’exécuter de manière générale car il explore tous les chemins possibles jusqu’à trouver un optimum (local dans certains cas particuliers (considération du temps d’exécution de branches parallèles), et global dans les autres).

4.1.3.1 Analyse du temps de réponse moyen en fonction du nombre de services disponibles dans le graphe initial

Pour produire les résultats présentés par la suite, chaque graphe a été transformé puis exploré au moins 10 fois pour produire une moyenne par fichier ainsi qu’une moyenne globale.

Transformation de graphes : Par l’analyse de ces résultats on remarque que le temps de réponse, notamment de la transformation de graphes va avoir une complexité polynomiale plus le graphe à transformer sera complexe. Cela est dû au moteur de transformation de graphe qui applique les règles de manière non linéaire (fonctionnement par priorité d’application) et qui tente d’appliquer toutes les règles dans un certain ordre jusqu’à non applicabilité de toutes les règles.

4.1. Temps de réponse des composants et performance 95

Comme on peut le remarquer sur la Figure 4.4, le temps de transformation peut aller de 257 ms en moyenne jusqu’à un peu plus de 10 secondes dans le pire des cas. Pour plus de précision dans l’analyse du comportement de graphe d’autres ré-sultats ont été mesurés. Dans la Figure 4.3 (détail des valeurs en Annexe D.1, Table D.1), on peut observer le temps moyen de transformation de graphes dans différents cas (global, avec un besoin simple ou un besoin double) en fonction du nombre de services initialement présents dans le graphe. Un besoin simple va être représenté par un nœud temp. ne comportant qu’une seule entrée et une seule sortie.

A contrario, un nœud double comportera lui deux entrées et deux sorties.

0 2 4 6 8 10 12 14 5 10 15 20 25 30 T em p s d e r ép o n se m o y en (s)

Nombre de services initialement présents dans le graphe

Plan exécutable Plan non exécutable Besoin simple Besoin double Moyenne globale

Figure 4.3 – Temps moyen de transformation de graphe dans le cas global et dans le cas où le besoin est simple ou double

Le comportement de la transformation s’avère en effet plus laborieux dans le cas où il y a beaucoup de services disponibles pour un besoin donné et également en fonction du nombre de types de contenus considérés (entrée·s / sortie·s). Plus le nombre de services disponibles est élevé et moins ces services répondent de manière proche au besoin, plus le temps de transformation sera long. En effet, dans le cas où de nombreux services sont disponibles et ne correspondent que partiellement au besoin (voire pas directement), un grand nombre de transformations intermédiaires sont nécessaires pour les intégrer au plan de composition. Également, dans le cas où il y a beaucoup de services qui correspondent au besoin, la grammaire va appliquer un plus de fois les règles permettant d’insérer ces nœuds dans le graphe. De plus, il arrive que des branches soient considérées comme mortes à la fin de la trans-formation car elle ont été raffinées avec de nouveaux besoins auxquels il n’existe finalement pas de réponse possible, même indirectement.

D’un autre côté, la présence d’un nœud temp. double dans le graphe initial va rallonger le temps d’exécution. En effet, dans ce cas, la transformation de ce nœud peut conduire à l’introduction de plusieurs nouveaux nœud temp. dans le graphe en cours de transformation si aucun service ne peut répondre tel quel au besoin, comme on peut le constater sur le temps moyen d’exécution.

Exploration des graphes transformés : Dans la Figure 4.4, le temps de réponse moyen des graphes d’exploration (exploration du graphe avec les deux al-gorithmes proposés) est présenté en fonction du nombre de services initialement disponibles dans le graphe à transformer.

0,00 0,50 1,00 1,50 2,00 2,50 3,00 3,50 5 10 15 20 25 30 T em p s d e r ép o n se m o y en (m s)

Nombre de services dans le graphe initialement Exploration glouton Exploration optimum

Figure 4.4 – Temps de réponse moyen des algorithmes d’exploration en fonction du nombre de services disponibles dans le graphe initial

On remarque que le glouton va avoir un temps d’exploration inférieur à l’algo-rithme de recherche d’optimum. Cela s’explique par le fait que le glouton va accepter le premier plan trouvé là où l’autre algorithme va explorer plus de possibilités pour rechercher un optimum. En revanche, lorsque l’on regarde ces temps d’exécutions sur une échelle logarithmique on remarque que le temps de réponse moyen des al-gorithmes va être d’un ordre 100 à 1000 fois plus rapide que la transformation. La complexité de ces algorithmes est en effet limitée par la profondeur et la largeur peu élevées des graphes explorés.

De ce fait, suivant les cas d’utilisation on va pouvoir considérer que ce temps d’exécution sont relativement négligeables par rapport à la transformation de graphe

4.1. Temps de réponse des composants et performance 97

(notamment dans le cas de graphes complexes à transformer).

Il est important de noter cependant qu’il sera rare d’atteindre de telles propor-tions en terme de complexité de transformation dans un cas réaliste car la com-plexité à gérer sera limitée par la phase d’analyse et le nombre de types de contenus sera limité en fonction du scénario géré lors de la prise de décision. Ces tests sont théoriques afin de dimensionner la réponse du système.

4.1.3.2 Comparaison des résultats produits et de performance tempo-relle des algorithmes d’exploration

Sur la base des graphes générés pour les tests précédents, d’autres résultats ont été exploités à savoir les résultats des explorations, i.e. les plans d’exécutions "choi-sis" par les algorithmes et une comparaison de résultat entre les deux algorithmes. De plus, une comparaison de performances (en terme de temps d’exécution) est réalisée afin de tempérer l’efficacité de l’algorithme de recherche d’optimum par rapport au glouton.

Ces résultats sont présentés dans la Table 4.1. Les comparaisons de performances réalisées sont définies de la manière suivante :

• les améliorations de résultats représentent l’amélioration de résultat (opti-malité du plan choisi) par l’algorithme de recherche d’optimum par rapport à la solution fournie par le glouton, elles sont notées perf_r avec cout[glou] le coût total du résultat trouvé par l’algorithme glouton, et cout[opti] le coût total du résultat trouvé par l’algorithme de recherche d’optimum :

perf_r = cout[glou] − cout[opti] cout[glou]

• les améliorations de performances temporelles représentent le gain en temps d’exécution qu’offre le glouton par rapport à l’exécution de l’algorithme de recherche d’optimum, elles sont notées perf_tavec temps[glou] le temps total d’exécution de l’algorithme glouton, et temps[opt] le temps total d’exécution de la recherche d’optimum :

perf_t= temps[opt] − temps[glou] temps[opti]

Certains résultats ne sont calculés que pour les cas où une solution a été trouvée (cas résolu).

Comparaison des résultats produits (plan d’exécution final : Pour cer-tains cas, notamment les cas où il n’y a qu’une seule solution possible ou aucune solution, les deux algorithmes vont retourner le même résultat. De ce fait, l’algo-rithme de recherche d’optimum n’apportera aucune amélioration par rapport à la solution fournie par le glouton (0% d’amélioration de résultat). N.B. : Dans les tests théoriques ici réalisés, de nombreux graphes ne comportent pas de solution :

Nb. Services 5 10 15 20 25 30 Moyenne temps[glou] 0,71 0,81 0,87 1,04 0,93 0,94 Moyenne temps[opt] 1,93 2,05 2,35 3,03 2,82 2,98 Moyenne perf_t 63% 60% 62% 64% 67% 67% Min. perft 13% -111% -64% -27% 14% 12% Max. perft 82% 81% 77% 93% 82% 87%

Min. perft (résolu) 68% 29% 18% 29% 37% 12%

Moyenne perfr 0% 1% 3% 3% 5% 6%

Max. perfr 0% 32% 60% 92% 68% 79%

Moyenne perfr (résolu) 0% 3% 8% 7% 8% 8%

Table 4.1 – Comparaison de performance temporelle (ms) et de qualité des résultats des algorithmes d’exploration (recherche gloutonne et recherche d’optimum)

en effet, l’ensemble de services générés aléatoirement ne permettent pas d’obtenir un plan d’exécution répondant au besoin aléatoirement généré. Cependant dans un cas réaliste, le graphe généré par l’analyseur comporterait plus de services potentiel-lement utilisables et disponibles dans l’environnement à l’instant considéré que dans les tests théoriques où les services sont aléatoirement générés de par la présence de la phase d’analyse en amont.

Ainsi, dans le cas de petits graphes (5 à 10 services disponibles) l’algorithme de recherche d’optimum va souvent (voire toujours) trouver la même solution que le glouton. Les améliorations de solution fournie seront donc quasi nulles.

Cependant, dans le cas de graphes plus complexes, l’algorithme de recherche d’optimum va fournir une meilleure solution que l’algorithme glouton au prix d’un temps d’exécution plus long en moyenne. Ainsi, on peut observer dans certains cas extrêmes une amélioration de presque 100% du résultat fourni (ce qui veut dire que le coût total d’exécution du plan sélectionné par la recherche d’optimum est réduit là où le coût d’exécution total du plan fourni par le glouton est presque deux fois supérieur). Dans les cas où une solution existe, (cas résolu), la recherche d’optimum va permettre d’améliorer le résultat en moyenne de 3 à 8% quand il y a plusieurs solutions.

Comparaison des performances temporelles : Par rapport au temps d’exé-cution de ces algorithmes, le glouton va s’exécuter en moyenne en moins de 1 milli-seconde et la recherche d’optimum en 2 à 3 ms. En effet, étant donné que le glouton va explorer d’abord en profondeur les graphes là où la recherche d’optimum va explorer en largeur en priorité, le glouton aura un temps d’exécution plus court. Cependant, de manière globale, le temps d’exécution des algorithmes d’exécution va être environ 100 à 1000 fois plus rapide que la transformation de graphe qui sera de l’ordre de la seconde à la dizaine de secondes dans le pire cas.

D’un autre côté, si l’on compare le temps d’exécution de l’algorithme glouton par rapport au temps pris par la recherche d’optimum, le glouton présente un gain de 65% en moyenne en terme de temps d’exécution, ce qui veut dire que le glouton a été

4.1. Temps de réponse des composants et performance 99

plus d’1.6 fois plus rapide. En effet, le glouton se contentant de prendre la première solution trouvée en explorant en profondeur, ce dernier va en général s’exécuter beaucoup plus rapidement que la recherche d’optimum.

Cependant, dans certains cas particuliers, notamment dans le cas de graphes plus complexes comportant des branches mortes, le glouton peut prendre plus de temps à s’exécuter que la recherche d’optimum de par son mécanisme d’exploration en profondeur et de retour en arrière. Par exemple, sur un graphe particulier, le glouton a pris plus de 2 fois le temps pris par la recherche d’optimum (−111%) pour s’exécuter.

Cependant, les cas où le glouton prendra plus de temps à s’exécuter ne se ren-contre que lorsqu’il n’y a pas de solution trouvée. En effet, lorsque l’on compare les résultats sur min perf_t dans le cas général et le cas où il y a une ou plusieurs solution·s, il n’y a pas de cas avec un ration négatif.

En bref, de manière générale, l’algorithme glouton va représenter un gain en temps d’exécution de plus de 60% par rapport à la recherche d’optimum ce qui représentera quelques ms de moins là où dans certains cas l’optimum sera plus rapide mais surtout peut apporter un gain significatif d’optimisation du coût d’exécution des services retenus dans le plan final.