Evalution à échelle réduite

L'objectif de cette section est d'évaluer la plateforme DASIMA dans un contexte à échelle réduite. Ces résultats ont fait l'objet d'une publication [MkL09].

7.4.1.1 Environnement d'évaluation

Nous avons évalué DASIMA sur un réseau local de 4 PC. L'ordinateur principal qui a hébergé DASIMA dispose de la conguration suivante : 1 processeur de 1.6 GO et 2GO de RAM. Les n÷uds M2M ont été déployés sur des machines distantes dotées d'un processeur de 1.6 GO et de 1GO de RAM. La gure 7.10 décrit l'architecture globale de l'environne-ment de test et d'évaluation que nous avons mise en place. Le nombre de de n÷uds M2M est indiqué en bas de chaque machine.

Fig. 7.10  Platefome d'expérimentation à échelle réduite 7.4.1.2 Evaluation du service gestion des évènements

Le scénario que nous avons mis en place consiste à déployer des n÷uds M2M sur les trois machines M1, M2, M3. Ces n÷uds ont été congurés pour envoyer des notications concernant leurs états selon une fréquence régulière (toutes les 1, 10, 50, 100, 1000 se-condes). Nous avons mesuré par la suite le temps de binding entre le conteneur des ME et l'application d'administration. Nous avons mesuré également le temps de traitement et de mise à jour des MEs.

Les graphiques 7.11(a) et 7.11(b) décrivent les résultats obtenus durant cette campagne d'évaluation. Nous pouvons constater que l'évolution du temps de traitement des

évène-ments n'est pas parfaitement proportionnelle à l'évolution de la fréquence d'émission des évènements. En eet, cette évolution tend à se stabiliser dans les deux graphiques.

(a) Temps de transfert des évènements des MEs

vers les MAs ^{(b) Temps de traitement et mise à jour des MEs}

Fig. 7.11  Evaluation du temps de traiment du service gestion des évènements Le second constat est que le rythme d'évolution du temps d'acheminement des mes-sages entre MEs et MAs évolue à un rythme inférieur au rythme d'évolution du temps requis pour la mise à jour des MEs suite à la réception d'une notication. Cette évolution trouve son explication dans la complexité des opérations de mise à jour (parcours des MEs hiérarchique, récupération des interfaces de mise à jour, opération de mise à jours) par rapport aux opérations de transfert de messages (simple routage de message en FIFO).

Les gures 7.11(a) et 7.11(b) illustrent l'évolution du temps de traitement des évène-ments suite à l'évolution de leur fréquence d'émission par les ressources administrées.

Un autre scénario à échelle réduite a été mis en place an d'évaluer les deux modèles de collecte de données (pull et push). Nous avons testé cette fois une communication JMS entre les ressources M2M et les MEs. Le scénario s'est déroulé comme suit :

1. Génération de congurations de n÷uds M2M selon la table 7.2, 2. Déploiement sur une seule machine M0 des MEs de des n÷uds M2M, 3. Tests des deux modes pull et push,

4. Collecte des mesures du temps de transfert des messages.

Nous avons décomposé le temps de transfert de message an de voir quelle partie du traitement consomme plus de temps lors du transfert des message entre MR et MEs. Nous nous sommes donc focalisé sur trois ∆ temps.

 T1 : Le temps passé entre la ressource administrée et le n÷ud d'administration M2M,  T2 : Le temps passé dans le n÷ud d'administration M2M avant d'envoyer au ME

concerné,

 T3 : Le temps de transfert des messages entre le n÷ud d'administration M2M et le ME DASIMA.

Tab. 7.2  Table de paramétrage des tests du service de gestion des évènements

Scénarios NbrNoeuds NbrLiens TailleCnx Fréq chang état Fréq pull

1 10 5 1000 1000 1000 2 2 1 1000 25000 1000 3 2 1 1000 1000 1000 4 2 1 1000 250 1000 5 2 1 1000 25 1000 6 2 1 1000 500 1000 7 2 1 1000 500 1000 8 2 1 1000 500 100 9 2 1 1000 500 200 10 2 1 1000 500 2000 11 2 1 1000 500 500

(a) Mesure du temps d'acheminement des

évènements en mode push ^{(b) Mesure du temps d'acheminement des}évènements en mode pull

Fig. 7.12  Mesure des temps en mode push et pull

En analysant ces deux graphiques on peut constater que, dans les 11 scénarios, la portion la plus importante du temps total est passé entre le n÷ud d'administration et la ressource administrée (le n÷ud M2M dans notre cas). Nous ne pouvons pas ajuster ce temps pour ne pas perturber le déroulement de l'activité du réseau de n÷uds administrés. Le second constat est que les temps T2 et T3 sont relativement faibles. Cela est dû au paramétrage de l'envoi des notications et à la fréquence de pull que nous avons adopté. Le scénario 11 illustre le cas où l'on allonge la fréquence du pulling. Il en résulte un pic au niveau de la courbe du T2.

Un toisième constat est que dans notre cas, le temps de transfert en mode push est réduit d'un facteur 3 en mode push par rapport au mode pull. En eet, en mode push, on réduit considérablement le temps de transfert de la notication entre le n÷ud administré et le n÷ud d'administration, ce qui explique une amélioration considérable du temps de transfert des notications.

7.4.1.3 Evaluation du service de gestion de binding

Cette évaluation consiste à mesurer le temps nécessaire pour établir la chaîne de liaison entre une application d'administration déployée dans DASIMA et un ME de type M2M géré. L'objectif de cette évaluation est de pouvoir estimer le temps moyen de binding d'une interface ou de toutes les interfaces d'administration exposées par un ME. Le graphique 7.13 décrit le résultat de notre scénario avec 10, 100 et 1000 n÷uds. Nous pouvons constater que le temps requis pour le binding de toutes les interfaces n'évolue pas proportionnellement au nombre d'interfaces bindés. Cela est dû à la factorisation du temps d'accès au ME dans le cas où on récupère toutes les interfaces.

Fig. 7.13  Evaluation du temps de traitement du service de gestion de binding