|
Utilisation d
Les profilers sont des outils qui mesurent la performance des applications et
assistent les développeurs dans l’identification des fragments de code pouvant
la dégrader. Les profilers existant actuellement sur le marché relèvent d’une ou
plusieurs des catégories suivantes :
La première catégorie fait appel aux fonctionnalités de monitoring déjà
intégrées à la JVM. En fait, le développeur n’a pas besoin d’un profiler pour
accéder aux dites fonctionnalités. Dépendamment de la version utilisée, il peut
les manipuler directement par le biais des interfaces JVMPI (88) ou JVMTI (89) . L’apport
des profilers de cette première catégorie se situe essentiellement au niveau de
l’utilisabilité des interfaces (GUI) et de la lisibilité des résultats.
Figure 12: Interactions entre le Profiler et la JVM
Dans la figure 12, le rôle de l’agent est de gérer la communication entre la
JVM et le Profiler notamment lorsque ce dernier est installé sur une machine
distante (Rappelons que l’installation du Profiler sur une machine différente de
celle de l’application permet de réduire la consommation des ressources
(mémoire, CPU…) engendrée par le processus de mesure. Ceci étant un profiler ne
doit pas consommer plus de 5% des ressources de la machine testée (90)).
La deuxième catégorie de profilers utilise des techniques de mesure qui
ressemblent à bien des égards à celles présentées dans la section 2.2.1.2. Les
mécanismes de fonctionnement sont néanmoins différents parce que les compteurs
de cette deuxième catégorie sont :
• Générés automatiquement.
• Injectés directement dans le byte code de l’application.
• Basés sur des algorithmes plus élaborés.
• Optimisés pour réduire la consommation des ressources au strict minimum.
• Supprimés automatiquement du byte code lorsque les mesures sont terminées.
Comparée aux profilers qui utilisent les interfaces de la JVM, cette deuxième
catégorie consomme moins de ressources parce que les messages et les événements
générés massivement par la JVM sont désactivés.
Notons par ailleurs que les profilers de la première catégorie ne fournissent
que des mesures générales relatives à la consommation des ressources (91) alors que
la deuxième catégorie permet d’associer des mesures beaucoup plus ciblées aux
différentes classes et interfaces de l’application.
Les fonctionnalités de la troisième catégorie de profilers sont intégrées au
serveur d’application. Elles sont généralement accessibles via des API qui se
basent de plus en plus sur les Java Management Extensions (JMX). (Le tableau 9
fournit une liste non exhaustive de produits utilisant JMX ).
JMX est un framework qui permet d’administrer et de surveiller à distance des
applications Java, mais également les composantes matérielles d’un réseau (PC,
serveur, routeur,...). Comme le montre la figure 14, les MBeans (managed
resources and management beans) se trouvent au cœur de ce framework. Ils
correspondent concrètement à des Java Beans qui permettent à des objets écrits
en Java de disposer d’une interface contenant les informations et les leviers de
contrôle nécessaires à leur surveillance et à leur administration.
Tableau 9 : Liste non exhaustive de produits utilisant JMX
(92)
JMX est présenté rapidement dans cet
article. Cette présentation est limitée à son architecture globale et aux possibilités offertes en matière
de surveillance des performances.
Notes de bas de
page
(88) Pour la JVM 1.4
et les versions antérieures
(89) Introduite dans la version 1.5 elle est plus robuste et consomme moins de
ressources que JVMPI.
(90) Source: Ali Syed and Jamiel Sheikh, Java Doctor, Manning Publications ,
Spring 2005,
http://www.theserverside.com/articles/article.tss?l=JavaDoctorBookInReview
(91) Occupation de la mémoire, nombre de threads actifs, pourcentage du CPU
consommé…
(92) Source : Benjamin G. Sullins and Mark B. Whipple , JMX in Action, Manning,
ISBN 1930110561, October 2002
|
Accueil 
Optimisation 
