Optimisation des protocoles JXTA et évaluations

Évaluations initiales. Le tableau 10.1 résume les performances initiales en termes de dé-bit et de latence des couches de communication de JXTA-J2SE 2.3.2 et JXTA-C 2.2 sur un réseau Gigabit Ethernet, en SAN. Elles représentent les performances initiales de ces inter-giciels telles que nous les avons évaluées. Les courbes correspondantes sont disponibles à l’annexe A.2.1. Comparées aux performances dessockets BSD, nous pouvons constater que les performances en termes de latence ne sont pas bonnes : entre 149µs et 711 µs selon les couches et le langage d’implémentation contre entre 39µs et 46µpour lessockets BSD. En outre, les débits présentés de JXTA-J2SE (80 Mo/s) ne sont atteints que pour une taille de messagestimportante : pour les canaux unidirectionnelstest égal à 16 Mo et pour le service point-à-point la valeur detest 4 Mo. Les courbes de débits de JXTA-C sont plus proches des performances dessockets BSD : elle accuse au mieux un retard de seulement 14,5 Mo/s, contre 31 Mo/s au mieux pour JXTA-J2SE. Ces débits sont rapidement atteints par JXTA-C, c’est-à-dire pour de faibles tailles de messages (t = 256ko). Cependant, au-dessus de cette taille les performances stagnent, contrairement aux performances dessocketsBSD. Ces mau-vais résultats sont principalement dus à un mécanisme coûteux de limitation de la taille de message émis pour JXTA-J2SE et une couche de communication relativement récente qui est en cours de développement pour JXTA-C.

Les performances en WAN de JXTA-J2SE et JXTA-C sont comparables aux perfor-mances dessockets: quasi-saturation du lien à 1 Gb/s utilisé pour ces tests (débit de 98 Mo/s comparé à 104 M pour unesocketC). De tels débits peuvent être atteints sous réserve d’une configuration adéquate de la taille des tampons TCP pour être en accord avec le produit

débit_∗ délaides caractéristiques de la liaison. Dans notre cas, cela donne une valeur pour la taille des tampons TCP de 1,9 Mo/s3. Enfin, la taille totale d’un message JXTA conte-nant 1 octet applicatif est de 961 octets pour un canal unidirectionnel (r = 0,1 %) et de 233 octets pour le service point-à-point (r = 0,4%)4. Une présentation plus détaillée de ces résultats sur différentes versions de JXTA-J2SE et JXTA-C, ainsi que des évaluations sur des réseaux Fast Ethernet (100 Mbits) et Myrinet-20005, sont disponibles dans [5, 6, 12].

Les performances des couches de communication de JXTA-J2SE et JXTA-C en WAN ne pénalisent pas les transferts de données entre les différents sites d’une grille. En revanche, les performances des couches de communications de JXTA-J2SE et JXTA-C en SAN limitent l’utilisation efficace des capacités de ces réseaux lors des transferts de données dans JUX -MEM. L’architecture des grilles de calcul est hiérarchique : faible latence au sein d’un SAN et forte latence en WAN. Les protocoles de cohérence utilisés tiennent compte de cette ca-ractéristique. Ainsi, ils favorisent les messages échangés dans un SAN, en privilégiant par exemple le passage du verrou associé à une donnée entre processus s’exécutant sur ce même SAN. De la même manière, lors du premier accès en lecture à une donnée au sein d’un SAN, un groupe local de gestion de cette donnée est créé afin d’éviter de coûteuses communica-tions en WAN. L’appartenance d’un ensemble de processus à un même SAN est définie par l’utilisation du même groupecluster, tel qu’il a été introduit dans l’architecture de JUXMEM

(voir section 5.2).

Optimisations. Une évaluation du code de l’implémentation des ces couches de commu-nication de JXTA nous a permis de constater que l’origine des ces importantes latences sur des SAN est triple. Premièrement, l’efficacitér des couches de communication de JXTA est faible. Deuxièmement, le code du chemin critique pour l’envoi et la réception d’un message n’est pas optimisé pour minimiser le temps de traitement. Troisièmement, une optimisation peut être réalisée dans le cas particulier où des communications directes entre les pairs sont possibles. Or, dans le contexte classique des systèmes P2P ce cas est une exception, mais il ne l’est plus dans le cas des grilles de calcul. Il devient même un cas standard. Nous avons donc jugé utile d’optimiser les couches de communication de JXTA pour une utilisation dans le contexte des grilles, l’objectif étant d’améliorer les performances des transferts de données au sein de JUXMEM. Pour la réalisation et la validation de nos optimisations, nous nous sommes concentrés sur le couple JXTA-C et JUXMEM-C. Toutefois, les mauvaises perfor-mances de JXTA-J2SE ont des origines similaires aux mauvaises perforperfor-mances de JXTA-C. Ainsi, les solutions que nous apportons sont applicables de manière similaire à JXTA-J2SE. Une description, plus détaillée, des optimisations proposées et implémentées est donnée ci-dessous.

Condensation et mise en cache d’éléments. Le service point-à-point ajoute deux éléments à chaque message JXTA émis : adresse source et adresse de destination (voir sec-tion 10.1.2). L’informasec-tion apportée par l’élément adresse source est incluse dans celle

3Obtenue par multiplication de la valeur théorique par un facteur arbitraire de 1,2.

4Pour TCP la taille totale d’un message de 1 octet est de 161 octets, soitr= 0,6%.

10.2 – Optimisation des performances pour les environnements de type grille 151

fournie par les messages de bienvenue, échangés avec le pair de destination lors de l’établissement de la connexion. Cette optimisation consiste donc à supprimer cet élément. Une partie de l’information apportée par l’élément adresse de destination, l’adresse TCP/IP du pair de destination, est également incluse dans les messages de bienvenue. Cette autre optimisation consiste en la réduction de l’élément adresse de destination à la seule information utile : le nom du service en charge du traitement du message lors de sa réception. Ces optimisations s’apparentent à la technique clas-sique de mise en cache des en-têtes (en anglais header caching), largement utilisée par différentes implémentations de protocoles réseaux.

Connexions directes. L’élément routeur peut être supprimé lorsqu’une connexion directe entre les pairs peut être établie. En effet, cet élément XML n’est pas nécessaire dans ce cas. En outre, lorsque l’adresse de destination est soit fournie sous la forme TCP/IP, soit présente dans une table de hachage du pair, ayant pour clé l’identifiant du pair de destination et comme valeur l’adresse TCP/IP associée, le protocole de routage n’est plus utilisé. Cette optimisation permet d’éviter le traitement XML associé de l’analyse lexicale de l’élément routeur, ainsi que la traversée de la couche logicielle implémen-tant le protocole de routage.

Mode zéro-copie. Cette optimisation consiste à enregistrer une fonction de rappel associée à un espace de nommage applicatif. Chaque élément d’un message JXTA peut en effet définir son propre espace de nommage (voir section 10.1.1). Chaque fois qu’un message JXTA reçu contient un espace de nommage enregistré, la fonction de rappel correspon-dante est appelée. Cette fonction doit retourner une adresse mémoire valide et d’une taille suffisante pour stocker la valeur de l’élément lu. Pour ce faire elle dispose du nom de l’élément. La donnée pourra alors être stockée directement dans la zone mé-moire allouée par l’utilisateur au niveau applicatif. Cette optimisation est utilisée au sein de JXTA pour limiter le nombre de copies mémoire, et éventuellement atteindre un transfert de données en mode zéro-copie lorsque l’encodage XDR n’est pas utilisé dans JUXMEM. Dans le cas contraire une copie est nécessaire (voir section 7.3.2). Le nom de l’élément dans les couches de communication de JUXMEMest son identifiant. Par ailleurs, l’utilisation des outils callgrind, greffon pour valgrind [134], et de

kcachegrind [225] nous a permis d’identifier les zones de code les plus coûteuses du chemin

critique utilisé pour l’envoi ou la réception d’un message JXTA. Chaque zone de code du chemin critique pour l’envoi et la réception d’un message a alors été étudiée, et si besoin réécrite.

Évaluations des optimisations. La figure 10.5 compare les performances en débit du ser-vice point-à-point et d’un canal unidirectionnel de JXTA-C 2.2 par rapport à leurs implé-mentations optimisées. Par ailleurs, cette figure présente également le débit d’une socketC en guise de courbe de référence. Nous pouvons constater que l’allure des courbes de débit pour les services optimisés suit celle d’une socketC. Les débits du service point-à-point et d’un canal unidirectionnel sont en effet de 110 Mo/s, soit un écart de 6,5 Mo/s par rapport à unesocketC. Ces valeurs sont obtenues pour des tailles de message de 1 Mo/s et 2 Mo/s pour respectivement le service point-à-point et un canal unidirectionnel. L’augmentation du débit par rapport à l’implémentation de JXTA-C 2.2 non optimisée est de 8 Mo/s et 15 Mo/s, pour respectivement le service point-à-point et un canal unidirectionnel. Cette augmentation est relativement faible.

Socket C 20 40 60 80 100 120 2Mo 512 128 64 32 16 8 4 2 1 0.5 Débit (Mo/s)

Taille des messages (ko) JXTA−C 2.2 service point−à−point non optimisé

JXTA−C 2.2 service point−à−point optimisé

0 Socket C 20 40 60 80 100 120 2Mo 512 128 64 32 16 8 4 2 1 0.5 Débit (Mo/s)

Taille des messages (ko) JXTA−C 2.2 canal unidirectionnel non optimisé

JXTA−C 2.2 canal unidirectionnel optimisé

0

FIG. 10.5 – Débit comparé du service point-à-point (gauche) et d’un canal unidirectionnel (droite) de JXTA-C 2.2 sur un réseau SAN Gigabit Ethernet, avec leurs implémentations optimisées, et en prenant pour courbe de référence le débit d’unesocketC.

Implémentation JXTA-C 2.2 non optimisé JXTA-C 2.2 optimisé

Canal unidirectionnel 294µs 90µs

Service point-à-point 149µs 84µs

BSDsockets 39µs

TAB. 10.2 – Performances en termes de latence du service point-à-point et d’un canal unidi-rectionnel de JXTA-C 2.2, comparées aux performances en latence d’unesocketC.

En effet, nos modifications6 visent principalement à optimiser les latences d’envoi et de réception d’un message JXTA. Le tableau 10.2 présente ces performances pour des ver-sions non optimisées et optimisées du service point-à-point et d’un canal unidirectionnel de JXTA-C 2.2. La latence d’un canal unidirectionnel en version optimisée est de 90µs, soit une amélioration de plus de 200µs ! Cela est principalement dû à l’optimisationconnexion directe

décrite précédemment. Selon nos mesures, elle représente une amélioration de la latence de 139µs qui s’explique principalement par l’absence du traitement XML de l’élémentrouteur

à chaque envoi/réception d’un message JXTA. Par ailleurs, elle correspond à une réduction de la taille du message de 684 octets, soit une amélioration de l’efficacité du protocole de 71 %. La latence du service point-à-point en version optimisée est de 84µs, soit un gain de 65µs. L’optimisationcondensation et mise en cache d’élémentsest la principale explication de cette amélioration de performance. En effet, la mise en cache de l’élément adresse source correspond à une réduction de la taille du message de 69 octets, soit une amélioration de l’efficacité du protocole de 30 %, au niveau du service point-à-point. La condensation de l’élément adresse de destination correspond à gain d’au moins 23 octets. Par ailleurs, les deux services bénéficient de diverses améliorations liées aux réécritures de codes.

La figure 10.6 présente le débit de la couche de communication de JUXMEM-C 0.2 com-paré au débit d’un canal unidirectionnel en version optimisée de JXTA-C 2.2, sur lequel elle repose. Par ailleurs et de manière similaire à la figure précédente, le débit d’unesocket C est également représenté à titre de courbe de référence. La couche de communication de

10.2 – Optimisation des performances pour les environnements de type grille 153 Socket C 20 40 60 80 100 120 2Mo 512 128 64 32 16 8 4 2 1 0.5 Débit (Mo/s)

Taille du message applicatif (ko) JuxMem−C 0.2 JXTA−C 2.2 canal unidirectionnel optimisé

0

FIG. 10.6 – Débit de la couche de communication de JUXMEM-C 0.2 sur un réseau SAN Gi-gabit Ethernet, comparé au débit d’un canal unidirectionnel en version optimisée de JXTA-C 2.2 et à unesocketC.

JUXMEM-C atteint le débit d’un canal unidirectionnel : 110 Mo/s pour une taille de message de 2 Mo/s. La latence est de 127µs, soit un surcoût de 43µs par rapport à la latence d’un ca-nal unidirectionnel de JXTA-C. Il s’explique par les deux éléments ajoutés (respectivement lus) pour chaque envoi (respectivement réception) d’un message JXTA. Ces éléments cor-respondent à l’identifiant du canal unidirectionnel du pair émetteur et à l’identifiant de la fonction de rappel à appeler sur ce pair de destination. Ces éléments ajoutent respectivement 78 et (au minimum) 16 octets à la taille d’un message JXTA, entraînant un surcoût de trai-tement. Par ailleurs, la création de l’objet JXTA représentant un identifiant est relativement coûteuse. Chaque message JXTA utilisé par JUXMEMutilise son propre espace de nommage rajoutant encore 8 octets à la taille d’un message JXTA. Ainsi, la taille totale d’un message de 1 octet transmis par la couche de communication de est de 303 octets.

Compte tenu des bons résultats de la version initiale de JXTA-C 2.2 sur des réseaux WAN, aucune évaluation de performances de la version optimisée en WAN n’a été effec-tuée, car aucun changement majeur dans les résultats n’est attendu. Par ailleurs, les perfor-mances en débit d’un canal unidirectionnel de JXTA-C étant comparables aux perforperfor-mances de la couche de communication de JUXMEM-C, aucune évaluation de celle-ci en WAN n’a été réalisée non plus.

Discussion. Pour conclure, les optimisations que nous avons réalisées ont permis d’amé-liorer la latence du service point-à-point et des canaux virtuels de JXTA-C 2.2. Elles consti-tuent un premier pas qui a permis de rendre utilisables ces couches de communication pour des transferts de données efficaces dans JUXMEM-C en SAN. Nos optimisations ont été par-tiellement intégrées dans JXTA-C 2.3, dernière version sur laquelle JUXMEM-C repose7. Par

ailleurs, les versions postérieures à JXTA-C 2.2 ont également en partie visé l’amélioration des performances de cette implémentation. L’objectif est d’approcher au plus près les per-formances dessocketsBSD, tout en gardant les fonctionnalités apportées par JXTA.

10.2.3 Utilisation de la plate-forme haute performance de communication pour