Mutualisation de requêtes XQuery sur des Flux RSS dans un environnement Pair-à-Pair

3.6 Résultats et comparaison

Pour tester l'efficacité de notre travail, on a utilisé comme plateforme celle réalisée par les étudiants des ISTY3 qui est constituée de 3 pairs. Notre proposition a été implémentée en PYTHON.

La performance de notre travail ne dépend pas du nombre des pairs du réseau, mais du nombre des pairs qui vont répondre à l'appel d'offre [3].

Pour effectuer les mesures, on a choisi une requête XQuery avec 1 seule restriction, et on a mesuré la performance de notre proposition dans le cas où un, deux et trois pairs veulent exécuter cette requête, en terme de, nombre de messages échangés via le réseau, et de la quantité des données y transitant, et on l'a comparée avec celle des ISTY3.

Nbre de messages

Nbre de pairs

Nbre de messages

60

120

180

1

2

3

1

2

3

Nbre de pairs

60

120

180

Figure 5 : Nbre de message VS Nbre de pairs voulant exécuter la cuté r la même requête en la mutualisant.

Figure 6 : Nbre de message VS Nbre de pairs voulant exécuter lcuté r la même requête ISTY3

3000

Nbre de pairs

Qté données (Ko)

1000

2000

1

2

3

1

2

3

Nbre de pairs

1000

2000

3000

Qté données (Ko)

Figure 7 : quantité des données (Ko) VS Nbre de pairs voulant oulant exécuter la même requête en la mutualisant.

Figure 8 : quantité des données (Ko) VS Nbre de pairs voulantoulant exécuter la même requête ISTY3.

3.6.1 Explications des résultats

D'après les figures 5 et 6, qui montrent le nombre de messages échangés en fonction du nombre de pairs exécutant une même requête, on constate que notre proposition (mutualisation) a réussi à baisser significativement le nombre de messages lorsque le nombre de pairs voulant exécuter la même requête augmente. Ceci peut être expliqué par le fait, que dans notre proposition, le premier pair va émettre et recevoir les messages nécessaires pour la localisation des sources pertinentes, et les messages destinés aux appels d'offres, par contre les autres pairs, n'ont qu'à récupérer le résultat en envoyant 3 messages : le premier message pour chercher s'il y a un pair qui a déjà pris en charge cette requête, le deuxième pour s'abonner, et le troisième pour récupérer le résultat.

A l'opposé du travail des ISTY3, où on remarque une augmentation linéaire du nombre de messages. Ceci est due au fait que tous les pairs échangent le même nombre de message pour l'exécution de la même requête.

D'après les figures 7 et 8, on constate également que grâce à la mutualisation, la quantité des données échangées via le réseau a nettement baissé, et si on la compare avec la quantité des données échangées sans mutualisation (ISTY3), on peut dire que notre proposition a diminué d'un taux de 85 % la quantité des données transitant via le réseau. On peut expliquer cette baisse pour le premier pair, par l'utilisation de l'approche e-commerce, qui mobilise que les pairs qui ont fait les meilleures offres. Et pour les autres pairs, par la mutualisation, c'est-à-dire que les autres pairs n'ont qu'à récupérer le résultat de chez le premier pair. A l'opposé de la figure 6, où chaque pair mobilise tous les pairs, ce qui engendre une redondance entraînant une augmentation vertigineuse de la quantité des données échangées via le réseau.