Performances et résistance au facteur d échelle d un agent de supervision basé sur JMX : Méthodologie et premiers résultats Abdelkader Lahmadi Laurent Andrey Olivier Festor LORIA - INRIA Lorraine - Université de Nancy 2 615 rue du Jardin Botanique F-5462 Villers-lès-Nancy, France {Abdelkader.Lahmadi,Laurent.Andrey,Olivier.Festor}@loria.fr RÉSUMÉ. L évaluation de performance des architectures de gestion de réseau et de service est devenue une nécessité pour les maîtriser et parfaitement connaître leur coût ainsi que leur impact sur les plates-formes gérées. C est dans ce contexte que nous menons un travail d évaluation d une architecture de supervision basée sur JMX, qui est devenu un standard pour la gestion des applications et des services dans le monde Java. Cet article présente les premiers résultats de ces travaux. Les résultats obtenus portent sur la résistance à la charge d un agent JMX. Nous illustrons notre approche par une évaluation des ressources système consommées sur l agent. Une évaluation de taux de réponses correctes en fonction du nombre de requêtes (get) en entrée de l agent est aussi présentée. ABSTRACT. Performance evaluation of network management architectures is being recognized as an important issue in the network management area. Performance analysis is required to acquire a better understanding of the management cost and its impact on the managed environment. To assess this cost, it is necessary to collect data about the performance of the management systems. To this end, we perform a performance evaluation study of a monitoring agent based on the JMX technology. Initial results of this study are presented in this paper. We illustrate our approach for one specific operation: polling based data retrieval. We have evaluated the ressource consumed by the agent. We have also evaluated the rates of agent responses in function of the injection rate of requests (get service). MOTS-CLÉS : Agent de supervision, JMX, performance,résistance au facteur d échelle. KEYWORDS: Management Agent, JMX, performance, scalability, benchmarking. Ce travail a été fait dans le cadre du projet RNRT Amarillo.
2 GRES, 28 Février-2 Mars 5, Luchon. 1. Introduction La performance des architectures de gestion est une préoccupation croissante dans le monde de la gestion des réseaux et des services. L expansion de l Internet, en taille et en nombre de services ainsi que l intégration de la gestion de ces services dans le plan fonctionnel ont accentué certains problèmes. Parmi ces problèmes citons l augmentation de la complexité des systèmes à superviser (comme par exemple les infrastructures de services pour des services universels) en terme du nombre des services opérationnels à gérer et leurs dépendances. Ces dépendances se caractérisent par des aspects temporels (dynamique, déterministe ou stochastique) aussi complexe que les aspects temporels de la structure des entités de ces services (fixe ou variable, stable ou instable). L explosion du nombre de composants à superviser et le déploiement à grande échelle de solutions connectant un nombre considérable de terminaux mobiles contribuent également au facteur d échelle que doit supporter la supervision. Ce genre de terminaux impose des contraintes fortes sur les ressources disponibles (CPU, mémoire et bande passante). Nous constatons aujourd hui un déploiement à grande échelle des applications basées sur la technologie Java couvrant la gamme allant de gros serveurs d applications à des plates-formes mobiles très contraintes (J2ME, MeXe, Micro-contrôleurs). Le standard de gestion SNMP [STA 98] est difficile à adapter pour la supervision de ce genre d applications [SUL 2] et ne s impose pas chez les développeurs de ces applications qui se tournent largement vers le standard de gestion JMX [SUN 2, SUN 3b]. L architecture JMX est généralement couplée au plan fonctionnel de l application à superviser et l agent de supervision est implanté sous la forme d un composant dans l application (par exemple le serveur d applications JBoss [JBO 99]). L impact de cette intégration des deux plans supervision et fonctionnel sur les performances semble minime pour les gros serveurs d applications disposant des ressources considérables. Cependant cet impact ne sera plus négligeable en terme de pourcentage de ressources octroyées au plan de gestion pour les terminaux beaucoup plus légers (PDA, téléphones portables,...). Les coûts de JMX n étant pas établis dans la littérature, son impact n est pas évaluable à ce jour. Pour combler ce vide nous avons entrepris un travail d évaluation présenté ici. L objectif de ce papier est de présenter un modèle de performance d un agent JMX en se basant sur la technique d évaluation de performance par mesure (benchmarking). Dans la section 2, nous examinons certaines études de performance des architectures de gestion. Ensuite dans la section 3 nous présentons brièvement les détails de l architecture JMX. Dans la section 4 nous présentons notre méthodologie d évaluation de performance pour une architecture JMX. Le modèle de performance de l agent associé est présenté dans la section 5. Les résultats préliminaires de notre étude sont présentés dans la section 5.5. Une conclusion et les travaux futurs sont présentés dans la section 6. 2. Travaux liés Plusieurs travaux ont porté sur l évaluation des performances des architectures de gestion. Ces études portent soit sur une approche unique [VIL 4, PAT 1], soit sur une comparaison entre plusieurs approches [PAV 4, NEI 4]. Ces études ont eu recours
Performances d un agent JMX 3 à des analyses expérimentales et analytiques. Les analyses analytiques modélisent le système à évaluer sous forme de variables et de paramètres en utilisant des techniques de modélisation standard comme les files d attentes [KLE 75] et ses multiples variantes ou en utilisant des réseaux de Pétri stochastiques [MAR 95]. L évaluation expérimentale se base sur des mesures effectuées sur un système réel ou un prototype, et les résultats ainsi obtenus peuvent servir pour valider les études analytiques. Avant de présenter notre modèle de performance basé sur une étude expérimentale par mesure pour un agent de supervision JMX, nous examinons certaines études d évaluation de performance qui ont porté sur des architectures de supervision basées sur SNMP ou les services Web. Le but est d identifier les méthodologies utilisées par ces études pour la techniques d évaluation de performance par la mesure (benchmarking). La technique de mesure a été utilisée dans plusieurs études [PAV 4, SUB, LUD 97] pour évaluer des prototypes d architectures de gestion de réseaux. Pavlou et al [PAV 4] ont ainsi évalué un prototype d une plate-forme de gestion basée sur les services web en mesurant le volume de trafic de gestion généré. Ils ont aussi mesuré le temps de réponse d un superviseur pour récupérer les informations de gestion provenant de variables dont le nombre varie selon le test considéré. Subramanyan et al [SUB ] ont procédé à l évaluation d un prototype d une architecture hiérarchique de gestion basée sur SNMP. Dans cette étude le système sous test est le manager (client SNMP) et ils ont mesuré le délai de monitorage, la consommation CPU et la résistance au facteur d échelle en variant le nombre des agents de gestion. Luderer et al [LUD 97] ont mesuré le temps de réponse au niveau du manager (client de gestion) sur un prototype d une architecture de gestion basée sur des agents Java intelligents. Ces études ont partiellement évalué les architectures de gestion proposées. L étude de Pattinson [PAT 1] portant sur une évaluation de performance expérimentale d un agent de supervision basé sur SNMPv1, est considéré comme complète. Elle vise l analyse du comportement de l agent associé. Nous contribuons à ces travaux en menant une étude consacrée essentiellement à l évaluation de performance d un agent de supervision JMX. Nous avons examiné ainsi l utilisation des ressources système qui est l une des métriques les plus analysée dans ces différentes études. 3. L architecture générale de JMX La première étape dans tout projet d évaluation de performance est de définir le système à évaluer. Dans notre contexte il s agit de l agent de supervision JMX. L approche JMX [FES 3] fournit une architecture et une API permettant la supervision des ressources pouvant s interfacer à une JVM (Java Virtual Machine). Ces ressources incluent des applications logicielles ainsi que des périphériques physiques. Tout comme pour la majorité des systèmes de supervision, JMX est basé sur une architecture (voir figure 1) en trois couches : le niveau instrumentation, le niveau agent et le niveau superviseur. Le concept de base de l architecture JMX est le MBean. Un MBean est un objet Java qui respecte un certain patron de programmation et il est utilisé pour instrumenter les ressources. Il forme la base du niveau instrumentation. Tout
4 GRES, 28 Février-2 Mars 5, Luchon. Figure 1. L architecture générale de JMX MBean est accédé au travers d un conteneur appelé MBeanServer. Il offre à l agent l ensemble des méthodes pour créer, détruire un MBean, lire des attributs, modifier des attributs et invoquer des méthodes sur les MBeans. Afin de permettre aux applications de supervision d accéder aux MBean, l architecture JMX propose deux types d accès à distance : les connecteurs et les adaptateurs de protocoles. Un connecteur permet à un client de faire des appels de méthodes à distance sur le serveur des MBeans. Typiquement un connecteur peut être bâti au dessus de RMI (Remote Method Invocation) [GRO 1]. Les adaptateurs de protocoles sont des composants côté serveur qui assurent la liaison entre des protocoles spécifiques (par exemple SNMP ou HTTP) et les services locaux d un serveur des MBeans. Le niveau superviseur comporte l ensemble des applications de supervision et outils d accès aux informations fournies par les agents. Dans le monde JMX, quatre types de MBean adaptés chacun à un profil d instrumentation donné sont définis. Ces MBeans sont : Le MBean standard : il s agit du plus simple des MBeans. Il doit implémenter sa propre interface de supervision qui définit les signatures des méthodes d accès aux attributs et opérations disponibles depuis l agent. Le MBean dynamique : La dénomination dynamique pour ces MBeans vient du fait que l interface de supervision de ces MBeans n est pas figée à la compilation mais fournie par les MBeans eux-mêmes à l exécution. Le MBean modèle : Il s agit de MBeans dynamiques qui fournissent un cadre d utilisation générique. En effet, ils permettent la création des MBeans sans codage de classes à partir d un MBean générique via un service d initialisation. Le MBean ouvert : Ce sont des MBeans dynamiques spécifiques. En effet, ils possèdent les mêmes caractéristiques que ces derniers mais restreignent les types de données pour leurs attributs, constructeurs et opérations à un sous ensemble défini de classes java sérialisables. 4. Une méthodologie d évaluation de performance des architectures de supervision L évaluation de performance d une architecture de supervision ou plus généralement d un système distribué est une tâche cruciale et qui n est pas systématique
Performances d un agent JMX 5 [JAI 91]. Elle nécessite une maîtrise du système à évaluer et la sélection d un ensemble de paramètres jouant un rôle important dans le processus d évaluation de performance du système. Ce processus d évaluation de performance nécessite la sélection des techniques d évaluation à utiliser, les métriques, les paramètres, les facteurs de performance et la charge (workload). Nous présentons une définition de ces différentes notions dans le contexte d évaluation d un agent JMX. Le système sous test est l agent JMX lui-même, plus l exécution du système d exploitation et autres éléments le supportant (la carte réseau, la pile IP, le machine virtuelle Java...). La méthodologie que nous proposons pour évaluer les performances de l architecture JMX se base sur la technique par mesure. Cette technique nécessite l instrumentation d un système réel. Cette instrumentation est parfois aussi coûteuse que le développement de l application elle même. L un des atouts de cette technique est qu elle nous fournit des résultats réels sur les performances de l agent. En contre partie cette technique nécessite un déploiement conséquent d une infrastructure réelle. Généralement, les résultats de la mesure serviront à valider des résultats obtenus par d autres techniques (analytique, simulation). Les métriques de performance [KAT 96] sont des critères de mesure que l on choisit pour quantifier les performances d un système. Nous avons utilisé deux types de métriques : les métriques de réponse et les métriques d utilisation. Le premier ensemble des métriques nous fournit le taux de réponse d un agent JMX en terme du nombre de requêtes correctes servies par seconde. Le second ensemble de métriques caractérise les ressources consommées sur la machine locale sur laquelle s exécute l agent. Ces ressources englobent trois critères qui sont : l utilisation CPU, la consommation mémoire et l utilisation réseau. Le choix de ces métriques n est pas arbitraire puisque ils nous seront utiles pour évaluer la fonction puissance P (Power function) [GIE 78] de l agent. Cette fonction qui est proportionnelle à la productivité de l agent et à son temps de réponse. Elle est utile pour évaluer d une façon analytique sa résistance au facteur d échelle [JOG ]. La charge (workload) est une notion importante dans le processus d évaluation d un système. Elle représente l ensemble de services demandés au système lors de son évaluation. Un agent JMX fournit plusieurs services (getattribute, getattributes,...) par l intermédiaire du MBeanServer pour administrer les ressources. Dans le cadre de tests présentés ici, nous avons utilisé un modèle de la charge représentatif d un polling de supervision en utilisant la méthode getattribute de l agent JMX pour récupérer les valeurs des MBeans. Chaque évaluation de performance nécessite la définition d un ensemble des paramètres qui vont avoir une influence sur les performances mesurées. Ces paramètres se divisent en deux catégories. Une première contient les paramètres censés être invariants. Elle comprend aussi bien les ressources matérielles que logicielles. Pour notre évaluation il s agit de la configuration matérielle de l agent et de ses clients ; leur système d exploitation, la capacité nominale du réseau et son taux d erreurs. La deuxième catégorie contient les paramètres modifiables appelés facteurs de performance qui ont une réelle incidence sur les performances et qui devront être modifiés lors du pro-
6 GRES, 28 Février-2 Mars 5, Luchon. cessus d évaluation. Nous avons classifié ces facteurs selon les critères d évaluations suivants : le passage à l échelle, la résistance à la charge, l importance du type des MBeans et l efficacité des implémentations. Deux facteurs de performance peuvent avoir de l influence sur le critère de passage à l échelle. Ce sont le nombre de MBeans instanciés dans l agent et le nombre d attributs d un MBean. La fréquence d injection des requêtes (la vitesse de polling) sur l agent est le facteur qui concerne la résistance à la charge. Le type de MBeans est un facteur important puisqu il détermine l impact de l usage de telle ou telle forme de MBeans, ceux-ci étant supportés différemment par l agent. Le type d implémentation JMX est le facteur qui offrira la possibilité de comprendre le comportement de chacune d entre-elles et en comparant leur efficacité. 5. Un modèle de performance basé sur la mesure pour un agent JMX Dans notre contexte, le système sous test est l agent JMX soumis à un jeu de tests synthétiques. Nous présentons ici deux jeux de tests relatif aux métriques présentées précédemment. Le premier scénario est le plus simple puisque il s agit d un MBeanServer contenant un seul MBean. Les mesures réalisées portent sur le nombre d attributs exposés par le MBean et la fréquence d accès maximale à ce ou ces attributs. L objectif de ces mesures est de connaître la relation qui existe entre le nombre d attributs et le taux de réponse de l agent. Le deuxième scénario consiste à mesurer l impact du remplissage d un MBeanServer. L agent comportera un nombre variable de MBeans munis d un seul attribut. Par conséquent les mesure tiendront compte du nombre de MBeans enregistrés dans l agent et le taux de réponse de l agent en terme du nombre de requêtes correctes servies par seconde lors de l accès à l unique attribut d un MBean choisi aléatoirement. Nous avons fait varié le type d implémentation de l agent. Les deux implémentations testées sont SUN-RI [SUN 3a] et MX4J [MX4 4]. Les types de MBeans varient selon les types définis par JMX i.e. le MBean standard, le MBean dynamique, le MBean modèle et le MBean ouvert. 5.1. Environnement expérimental Plusieurs solutions sont envisageables pour la mise en place d une plate-forme de mesure de performance. Des alternatives directement liées au consortium Objectweb existent déjà et consistent à l utilisation de CLIF [OBJ 3] qui est une plate-forme Java dédiée aux tests de performance, ou sur RUBIS [OBJ 2] qui utilise le mode scripté pour le lancement et la collecte de mesures. Notre préférence s est portée sur le modèle de benchmarking de RUBIS reposant sur un mode scripté et des utilitaires open-source. L application d évaluation de performance vise à tester des agents JMX basés sur des implémentations open-source grâce aux jeux de tests synthétiques décrits précédemment. L architecture de test repose sur trois parties qui sont : l agent qui constitue le système sous test, le client ou l injecteur qui sollicite l agent et la console qui gère la procédure de lancement et de monitorage des ressources consommées par l agent. Nous avons développé un prototype d agent de supervision basé sur des implémentations open-source de JMX. Cet agent ne comporte pas réellement des notions liées au benchmarking mais son comportement doit être le plus proche possible des conditions
Performances d un agent JMX 7 réelles d utilisation. La principale difficulté se situe au niveau de la modification de ses facteurs de performance. Ces facteurs sont essentiellement le nombre de MBeans, le nombre d attributs et le type d implémentation. Pour chaque type d implémentation la classe qui créé le MBean server et enregistre les MBeans est commune. Il suffit de copier les bonnes librairies avant le lancement de l agent. La création des MBeans n est pas aussi simple car il est parfois nécessaire de faire varier le nombre d attributs. Cela ne pose aucun problème pour les MBeans dynamiques puisque comme nous l avons évoqué précédemment, ils sont capables de faire varier leurs interfaces de management dynamiquement. Il n en est pas de même pour les MBeans standards dont les interfaces sont codées statiquement sous forme de code source Java. Pour ce type de MBeans, nous avons utilisé un moteur de substitution appelé velocity [VEL 2] qui permet de générer du code source à partir d un gabarit. L accès distant au MBeanServer pose un problème car toutes les implémentations ne respectent pas le JSR 16 [SUN 3b]. La solution consiste à utiliser une factory du côté du client et de l agent afin de masquer la manière dont sont fournies les méthodes d accès distantes. Nous avons pris le connecteur RMI/JRMP (Remote Method Invocation) comme un paramètre de performance et son utilisation est commune à l ensemble de nos tests. Le client (voir figure 2) ou le manager est implanté sous forme d injecteur de requêtes puisqu il s agit de générer tout un ensemble de requêtes getattribute. Une technique classique d injection sous forme de boucle s est avérée invalide puisque les requêtes sont réalisées en série de façon synchrone, ce qui n amène pas l agent à saturation. Le but est de se rapprocher d un comportement réaliste où toutes les requêtes sont réalisées en parallèle. La solution consiste à utiliser des threads qui effectuent une requête par seconde. Nous fixons la fréquence d injection en instanciant autant de threads que nécessaire. En effet, la résolution de la commande sleep calibrant l injection peut varier d un système à l autre, et peut induire une variance élevée pour de faibles délais. Moniteur Injecteur Injecteur Moniteur Console Log Log Stub Client Résultats collectés Flux des messages RMI Skeleton serveur Réseau Agent Moniteur Log Figure 2. Fonctionnement général de l application d évaluation
8 GRES, 28 Février-2 Mars 5, Luchon. La console est le contrôleur de toute la procédure de test. Son rôle est primordial puisqu elle est chargée du déploiement de l agent, des injecteurs et des moniteurs. Elle est aussi responsable de tout aspect relatif à la collecte et au traitement des résultats. Son fonctionnement repose sur un ensemble de scripts shell. Ces scripts enchaînent les différentes étapes d un test qui comporte la propagation des fichiers de configurations, le lancement de l agent, le lancement des injecteurs, le déploiement des moniteurs, la collecte des résultats et la génération du rapport d évaluation. 5.2. Environnement logiciel Nous avons testé les deux implémentations de JMX que sont SUN-RI v1.2.8 et MX4J v2.. Toutes les deux se basent sur la spécification 1.2 de JMX et fournissent un support du JMX REMOTE (JSR 16). Pour tous les tests nous avons utilisé la JVM de Sun sous forme du JDK 1.4._1 pour Linux. Nous avons choisi une distribution Slackware 9.1 comme système d exploitation qui utilise un noyau Linux en version 2.4.22. Nous avons réalisé une installation minimale afin de limiter le nombre des services actifs. 5.3. Plate-forme matérielle Nous avons utilisé quatre machines pour réaliser nos expérimentations. Chaque injecteur est composé d un PII 35MHZ avec 128Mo de RAM. L agent tourne sur un bi-processeur PIII 55MHZ avec 512Mo de RAM. Toutes les machines sont équipées d une carte réseau Ethernet Mbps et inter-connectées via un switch Cisco 26 series où seuls nos tests génèrent du trafic. 5.4. Méthodologie de mesure Nous avons suivi une méthodologie de mesure [CEC 2], afin de mieux réaliser nos mesures sur l agent et pour qu elles soient crédibles. Pour chaque test, le mode de fonctionnement des injecteurs se décompose en deux phases. Une première phase d initialisation de l agent est réalisée en augmentant progressivement la fréquence d injection jusqu à la valeur désirée (ramp-up). Dès lors, on enchaîne avec la phase de mesure où le nombre de requêtes par seconde est constant. Le but de cette opération est d éviter de solliciter trop brutalement l agent avec un taux d injection élevé. Si cette précaution n est pas prise, l agent sature complètement pendant une durée de quelques minutes et les mesures sont bien évidement faussées. Nous avons utilisé une durée de ramp de 1 minute pour une durée de test de 2 minutes, ceci dans tous les tests. Nos premières expériences de tests ont montré que la saturation de l agent pouvait provoquer celle de l injecteur. Cependant, il peut arriver que ce dernier sature si le nombre de requêtes par seconde désirées nécessite la gestion d un trop grand nombre de threads. Nous avons réalisé un premier ensemble de tests afin de calibrer les injecteurs en mesurant leurs capacités nominales d injection en fonction de la puissance de la machine. Pour garantir l injection prévue (facteur de test) sur l agent il suffit d utiliser le nombre suffisant d injecteur(s) fonctionnant sur les nœuds qui ne saturent pas.
Performances d un agent JMX 9 Nous considérons que le réseau n est pas un goulot d étranglement, vues les conditions décrites au 5.3. Pour mesurer la charge sur chaque machine, nous avons choisi le paquetage sysstat [GOD 3] qui contient la commande sar permettant la collecte à chaque seconde de l utilisation CPU, mémoire et réseau directement fournis par le noyau. Le fichier des résultats généré par cette commande est analysé post-mortem afin de minimiser les perturbations systèmes durant l expérience. Au cours d un test, il est essentiel de posséder un référentiel de temps commun. Il doit nous permettre de corréler ce qui se passe sur chacune des machines. La solution adoptée consiste à utiliser le protocole NTP [L.M 92]. La machine sur laquelle tourne la console est utilisée comme serveur NTP. Sur les clients nous avons fait tourner la commande ntpdate. Si elle ne permet qu une approximation de l ordre de la seconde, elle ne laisse aucun démon actif et n engendre aucune surcharge. Cette synchronisation est suffisante pour ajuster des courbes correspondant à des durées de tests de plus de 2 minutes. La gestion des résultats est une tâche importante de la console. Puisque qu elle se charge de récupérer les fichiers locaux enregistrés sur les différents nœuds, les analyse et créée une arborescence spécifique afin de pouvoir retrouver facilement les données. L essentiel des données est contenu dans les fichiers générés par SAR qui regroupent les informations sur l utilisation de ressources systèmes. Ces données sont analysées afin de dégager les valeurs des métriques définies précédemment (voir section 4). L obtention de valeurs fiables passe par la réalisation de nombreux jeux de tests à la suite desquels on procédera à leur corrélation. Les autres données sont des fichiers de compte-rendu (log) généré par les injecteurs (métriques de production et latence). 5.5. Résultats préliminaires Dans un premier temps, nous avons réalisé une série des tests unitaires en faisant varier la fréquence d injection pour positionner la zone de saturation de l agent et déterminer le taux de réponse maximal de l agent en terme de nombre de requêtes correctes servies par seconde. Celle-ci se manifeste par l écroulement du nombre de réponses de l agent par rapport à la charge d injection théorique de l injecteur. Nous serons ainsi en mesure de dégager le cadre d utilisation optimum de l agent. Nous avons pris l exemple de deux scénarios de test décrits précédemment. 5.5.1. Un MBean dans un MBeansServer Dans ce scénario de test nous avons considéré un MBean dans un MBeanserver avec un nombre d attributs variant entre 1 et. Nous avons déroulé ce test pour le deux implémentations MX4J et SUN-RI. Par exemple avec l implémentation SUN-RI et pour un MBean possédant un seul attribut, une première analyse nous a permis de positionner la zone d instabilité de l agent entre 6 et 725 requêtes par seconde. Ce seuil fixant le régime linéaire est variable selon le nombre d attributs exposés par le
1 GRES, 28 Février-2 Mars 5, Luchon. MBean. Les courbes de la figure 3 montrent les résultats de ce test. Nous obser- Réponses correctes de l agent/s 7 6 5 4 9 4 5 6 7 attributs avec MX4J 1 attribut avec MX4J attributs avec SUN-RI 1 attribut avec SUN-RI Figure 3. Comparaison des taux de réponse de l agent en fonction de la fréquence d injection sur un MBean standard comportant un nombre variable d attributs pour le deux implémentations mx4j et sun-ri pour le service getattribute. vons que le nombre d attributs à une influence directe sur les performances. La perte s avère plus perceptible entre les deux implémentations pour un nombre considérable d attributs. Ainsi, pour MX4J avec attributs le taux de réponse maximal se situe à req/s, celle-ci chute à 35 req/s pour SUN-RI. Nous constatons une perte de 5% du taux de réponse de l agent entre les deux implémentations. Pour expliquer ce gain de MX4J sur SUN-RI nous avons analysé le code source de deux implémentations, et nous nous sommes rendu compte que MX4J utilise un cache pour récupérer les références faibles (WeakReference) des instances des identifiants des MBean déjà allouées (définis par la classe Ob jectname) sans avoir à les instancier de nouveau pour chaque requête. Contrairement, l implémentation de SUN-RI crée un nouvel identifiant du MBean pour chaque requête. Ceci engendre un coût considérable en terme de mémoire et de CPU puisque la création d un nouveau objet Ob jectname nécessite le parsing d une chaîne de caractères identifiant le MBean. Cet aspect de cache utilisé par MX4J explique la stabilité au niveau de l utilisation mémoire pour un MBean standard avec 1 attribut et attributs (voir figure 4), ce qui n est pas le cas pour l implémentation de SUN-RI (voir figure 5). 5.5.2. Plusieurs MBeans dans un MBeansServer Dans le deuxième scénario nous avons mesuré l impact du remplissage du MBean server sur le taux de réponse maximal de l agent. L agent comporte donc un nombre variable de MBeans munis d un seul attribut. Nous avons déroulé ce test avec des MBeans standard en utilisant l implémentation MX4J. Nous constatons que le
Performances d un agent JMX 11 Utilisation des ressources en % 9 8 7 6 5 4 3 2 1 4 5 6 7 9 Utilisation des ressources en % 9 8 7 6 5 4 3 2 1 4 5 6 7 9 CPU Mémoire Réseaux Taux de réponse CPU Réseaux 1 Attribut Attributs Mémoire Taux de réponse Figure 4. L utilisation de ressources par l agent pour un MBean standard avec 1 attribut et attributs en utilisant l implémentation MX4J pour le service getattribute. Utilisation des ressources en % 9 8 7 6 5 4 3 2 1 4 5 6 7 9 Utilisation des ressources en % 9 8 7 6 5 4 3 2 1 4 5 6 7 9 CPU Mémoire Réseaux Taux de réponse CPU Mémoire 1 Attribut Attributs Réseaux Taux de réponse Figure 5. L utilisation de ressources par l agent pour un MBean standard avec 1 attribut et attributs en utilisant l implémentation SUN-RI pour le service getattribute. nombre de MBeans enregistrés sur le MBeanServer a peu d impact sur le taux de réponse maximal de l agent qui se situe aux alentours de 85 req/s que se soit pour un MBeanServer avec 5 ou MBeans standard (voir figure 6). Nous avons analysé le taux de réponse nominal de l agent que représente la valeur d injection pour laquelle nous avons un plus grand nombre de requêtes correctes servies. Cette métrique prend une valeur de 25 req/s pour attributs dans un MBean standard ou un MBean dynamique et pour MBeans avec 1 attribut chacun, elle est de 5 req/s (voir figure 8). Ainsi, nous pouvons constater que l impact sur les performances du nombre d attributs dans un MBean est plus important que le nombre des MBeans enregistrés dans le MBeanServer. Nous pouvons expliquer cette perte de taux de réponses de l agent par le coût important de l introspection Java et de la sérialisation dans le cas d un MBean standard avec un nombre considérable
12 GRES, 28 Février-2 Mars 5, Luchon. Réponses correctes de l agent/s 7 6 5 4 4 5 6 7 Mbeans avec MX4J 5 MBeans avec MX4J 9 Utilisation des ressources en % 9 8 7 6 5 4 3 2 1 CPU Mémoire 4 5 6 7 Taux de réponse Réseaux 9 Figure 6. Réponse de l agent en fonction de la fréquence d injection avec un nombre variable de MBeans standards et en utilisant l implémentation MX4J pour le service getattribute. Figure 7. L utilisation de ressources par l agent avec un MBeanServer contenant MBeans standard et en utilisant l implémentation MX4J pour le service getattribute. d attributs [M.S 4]. Cette perte diminue en utilisant des MBeans dynamiques au lieu des MBeans standard. Dans ce cas, nous serons pénalisés que par le coût de la sérialisation. Il faut noter que l accès à un attribut d un MBean dynamique est codé par une simple imbrication de if-then-else. 99 Taux de réponse de l agent en % 98.5 98 97.5 97 96.5 4 5 6 7 attributs/mbean standard attributs/mbean dynamique MBeans standards Figure 8. Comparaison du taux de réponses de l agent entre un MBean standard et dynamique avec attributs chacun et un MBeanServer avec MBeans standard et 1 attribut chacun en utilisant l implémentation MX4J pour le service getattribute. Les résultats de notre étude préliminaire sur les performances de l agent JMX, nous ont permis d identifier certaines directives sur le choix du type de MBeans et le fournisseur de l implémentation JMX. Nous constatons que l implémentation MX4J est plus robuste que celle de SUN-RI. Cette efficacité est dûe aux mécanismes d optimisation qu utilise MX4J. Pourtant, l implémentation SUN-RI est une implémentation de référence, que nous devons l examiner avec d autres scénarios de tests avec des MBeans dynamiques au lieu des MBeans standards. Nous constatons aussi
Performances d un agent JMX 13 que le remplissage du MBeanServer avec des MBeans consomme plus de mémoire que le remplissage d un MBean avec des attributs. Ce premier scénario consomme cependant moins de CPU que le second (1%). 6. Conclusion et travaux futurs Nous avons présenté dans ce papier une méthodologie d évaluation de performance d un agent JMX de supervision en se basant sur la technique d évaluation par mesure. Cette technique utilise la mesure sur une plate-forme réelle d un agent JMX. Cette technique souvent considérée plus réaliste que les autres techniques (simulation et analytique), nous a permis d identifier les difficultés et les contraintes de l évaluation de performance qui semble simple au premier abord. Les courbes de la figure 3 composées de quarante points nécessitant plus de quatre cents tests unitaires chacune. Si l on considère que pour être significatif, un test doit durer au moins une vingtaine de minutes, le temps nécessaire pour l obtention de ces dernières est d environ douze jours. Cette démarche est à répéter pour d autres valeurs au niveau des attributs, des MBeans et des implémentations, on s aperçoit de l ampleur de la tâche. Les résultats obtenus s avèrent restreints, mais mettent en évidence de réelles différences de performance entre les deux implémentations MX4J et SUN-RI. En effet, l implémentation MX4J semble plus efficace en terme de résistance à la charge que celle de SUN-RI. Dans des travaux futurs nous comptons poursuivre les tests unitaires en variant d autres facteurs de performance : type des MBeans (dynamique, modèle et ouvert), type d implémentation (JDK 1.5, JBoss-mx). L utilisation de la méthode getattributes est aussi à envisager en la comparant avec getattribute sur les workloads adaptés. Dans une deuxième étape, nous allons étendre notre évaluation sur le manager, pour entre autre évaluer la performance du service à notification. 7. Bibliographie [CEC 2] CECCHET E., MARGUERITE J., ZWAENEPOEL W., «Performance and Scalability of EJB Applications», Oopsla 2, 2, http://rubis.objectweb.org/download/perf_scalability_ejb.pdf. [FES 3] FESTOR O., ANDREY L., «Chapitre 6: JMX : un standard pour la gestion Java», p. 213 251, 3. [GIE 78] GIESSLER A., HAENLE J., KOENIG A., PADE E., «Free Buffer Allocation an Investigation by Simulation», vol. 2, n o 3, 1978, p. 191 28. [GOD 3] GODART S., «system performance tools for Linux OS», http://perso.wanadoo.fr/sebastien.godard/, November 3. [GRO 1] GROSSO W., Java RMI, O Reilly, October 1, ISBN: 565924525. [JAI 91] JAIN R., The art of Computer Systems Performance Analysis, John Wiley & Sons, Inc, 1991, ISBN : -471-5336-3. [JBO 99] JBOSS, «The Professional Open Source Company», http://www.jboss.org, 1999. [JOG ] JOGALEKAR P., WOODSIDE M., «Evaluating the Scalability of Distributed Systems», IEEE Trans. Parallel Distrib. Syst., vol. 11, n o 6,, p. 589 63, IEEE Press. [KAT 96] KATCHABAW M. J., HOWARD S. L., MARSHALL A. D., BAUER M. A., «Evaluating the costs of management: a distributed applications management testbed», Proceedings of the 1996 conference of the Centre for Advanced Studies on Collaborative research, IBM Press, 1996, Page 18. [KLE 75] KLEINROCK L., Queueing Systems Theory, vol. 1, Wiley-Interscience, New York, New York, 1975.
14 GRES, 28 Février-2 Mars 5, Luchon. [L.M 92] L.MILLS D., «Network time protocol(version3), RFC 135», http://www.ietf.org/rfc/rfc135.txt, March 1992. [LUD 97] LUDERER G. W. R., KU H., SUBBIAH B., NARAYANAN A., «Network Management Agents Supported by a Java Environment», Integrated Network Management, 1997, p. 79-79. [MAR 95] MARSAN M., G.BALBO, G.CONTE, S.DONATELLI, G.FRANCESCHINIS, Modeling with Generalized Stochastic Petri Nets, John Wiley&Sons, 1995. [M.S 4] M.SOSNOSKI D., «Java programming dynamics,part 2», developerworks, April 4. Java technology, IBM [MX4 4] MX4J, «Open Source JMX for Entreprise Computing», http://www.mx4j.org, April 4, Release 2.. [NEI 4] NEISSE R., VIANNA R. L., GRANVILLE L. Z., ALMEIDA M. J. B., TAROUCO L. M. R., «Implementation and Bandwidth Consumption Evaluation of SNMP to Web Services Gateways», NOMS (Network Operations & Managament Symposium), vol. 9, April 4. [OBJ 2] OBJECTWEB, «RUBiS: Rice University Bidding System», http://rubis.objectweb.org, 2. [OBJ 3] OBJECTWEB, «The CLIF Project», http://clif.objectweb.org, 3. [PAT 1] PATTINSON C., «A Study of the Behaviour of the Simple Network Management Protocol», DSOM (International Workshop on Distributed Systems: Operations & Management), October 1. [PAV 4] PAVLOU G., FLEGKAS P., GOUVERIS S., LIOTTA A., «On management technologies and the potential of Web services», Communications Magazine, IEEE, vol. 42, 4, p. 58-66, ISSN: 163-684. [STA 98] STALLINGS W., SNMP,SNMPV2,Snmpv3,and RMON 1 and 2, Longman Publishing Co., Inc., 1998. Addison-Wesley [SUB ] SUBRAMANYAN R., MIGUEL-ALONSO J., FORTES J. A. B., «A scalable SNMPbased distibuted monitoring system for heterogeneous network computing», Supercomputing : Proceedings of the ACM/IEEE conference on Supercomputing (CDROM), IEEE Computer Society,, Page 14. [SUL 2] SULLINS B. G., WHIPPLE M. B., JMX in Action, Manning Publications, October 2. [SUN 2] SUN, «Java T M Management Extensions, Instrumentation and Agent Specification, v1.2», http://jcp.org/en/jsr/detail?id=3, october 2, Maintenance Release 2. [SUN 3a] SUN, «Java Management Extension(JMX)», http://java.sun.com/products/javamanagement/index.jsp, August 3, Release 1.2.1. [SUN 3b] SUN, «Java T M Management Extensions(JMX TM ) Remote API 1. Specification», http://www.jcp.org/en/jsr/detail?id=16, october 3, Final Release. [VEL 2] VELOCITY, «The Apache Jakarta Project», http://jakarta.pache.org/velocity, 2, Release 1.3.1. [VIL 4] VILÀ P., L.MARZO J., BUENO A., CALLE E., FÀBREGA L., «Distributed network resource management using a multi-agent system: scalability evaluation», SPECTS (International Symposium on Performance Evaluation of Computer and Telecommunication Systems), July 4.