NISSR
La classe MyCatalogue
Elle modélise notre catalogue : les métadonnées. Elle permet d’avoir une vision globale de la base de données et sert ainsi d’appui aux routeurs pour leur faciliter le routage. Elle stocke l’état de chaque réplique : charge, fraîcheur, en panne ou non…
La classe MyProtocol
Elle représente les protocoles exécutés par les nœuds. Elle a un attributtype qui peut prendre trois valeurs possibles désignant chacune un type de nœud (TM Node, DBMS Node ou Client Node). Selon le type de nœud une exécution particulière est effectuée conformément au comportement du nœud.
La classe MyTransaction
Cette classe permet de regrouper toutes les informations concernant une transaction telles que son cycle (date) de lancement, son coût d’exécution… De ce fait à l’exécution d’une transaction on peut par exemple évaluer la durée de son traitement. Les objets de cette classe sont utilisés par les instances de la classeMyProtocol.
La classe NetworkInitializer
Au lancement de la simulation, elle initialise l’état du système :
Chargement du fichier de configuration;
Instanciation des différents types de nœuds;
Elle utilise certaines méthodes deMyProtocol pour la génération des types de nœuds.
La classe NetworkObserver
Cette classe sert à afficher les résultats de la simulation à l’écran et les met aussi dans un fichier. Les données récupérées à partir de cette classe seront utilisées pour le traçage de graphes d’évolution.
La classe NetworkManager
Elle sert uniquement à assurer l’aspect dynamique du système en générant à chaque cycle un nombre fixé de nœuds en panne choisis de façon aléatoire.
Expériences
Les expériences qui suivent ont pour objectif
a. de montrer l’impact du nombre de répliques sur le traitement afin de déterminer l’existence d’un nombre de répliques optimal s’adaptant au mieux au traitement.
b. de montrer les avantages et limites de notre traitement, tolérant aux pannes, par rapport à un traitement ne les tolérant pas.
c. de trouver le nombre de pannes au-delà duquel l’algorithme perd en termes de performance.
d. de comparer les approches de détection probabiliste et hiérarchique sur notre système (cf. chapitre 1, section 5.2.2).
Les transactions arrivantes au niveau de la base de données ont des coûts ou durées d’exécution variables de 1 à 3. Nous considérons qu’on a une réplication totale et définissons la puissance de traitement d’une réplique comme étant la somme maximale des durées d’exécution de transactions qu’il peut traiter en un cycle. De même la surcharge d’une réplique est la somme maximale des durées d’exécution des transactions qu’elle a en attente au-delà de laquelle la réplique est considérée comme surchargée. Une réplique surchargée ne répond à aucun message de communication même s’il s’agit d’un « ping » tant qu’elle est dans cet état. Ceci nous permet de nous approcher de la réalité puisqu’il y aura des fausses suspicions.
Pour chacune des expériences qui vont suivre, chaque DBMS Node a une puissance de traitement égale à 15 et pour surcharge 45. Le nombre de TM Nodes est fixé à 10. Nous utilisons le mode de fonctionnement par cycle du simulateur Peersim.
Impact du nombre de répliques sur le traitement
On vise à montrer l’impact du nombre de répliques sur le traitement. Pour ce faire, nous faisons varier le nombre de réplique de 60 à 380 et mesurons à chaque fois le pourcentage de transactions restantes (non traitées) à la fin de l’exécution au bout de 60 cycles. La fréquence des pannes est fixée à une panne par cycle, le délai d’attente des routeurs à 6 cycles et les exécutions concernent les débits de 40, 60 et 80 transactions par cycle. Nous avons le graphe des résultats suivant : Figure 4.1 : Impact du nombre de répliques sur le traitement
Nous remarquons que globalement le nombre de répliques influe positivement sur le traitement des transactions mais aussi que suivant le débit, certains nombres de répliques paraissent plus adéquats que d‘autres. En effet pour chaque débit (courbe) nous avons un point minimal à partir duquel la courbe fluctue pour tendre à la constante.
Comparaison avec un traitement ne tolérant pas les pannes
Cette expérience reprend les résultats de celle précédente pour un débit de 40 transactions par cycle et les compare à ceux d’un traitement ne tolérant pas les pannes. On a repris les contextes des expériences ci-dessus pour exécuter le traitement ne tolérant pas les pannes. Ce traitement ne s’occupe pas des nœuds en panne, il ne lance pas de procédure de détection pour ne pas parler de gestion de tolérance. La comparaison des résultats donne les diagrammes suivants : Figure 4.2 : Comparaison pour un débit de 40 transactions par cycle
Cette figure montre bien que la tolérance aux pannes influe de façon positive sur le traitement. Notons que plus le débit d’arrivée des transactions est grand par rapport au nombre de répliques, plus le système est surchargé, on a de fausses suspicions. C’est ce qui fait que sur la figure, le traitement avec tolérance s’approche d’un traitement sans tolérance pour des nombres de répliques peu élevés par rapport à la charge du système.
Télécharger le document complet
