Parce que tout est objet dans Java, l’approche la plus patente pour identifier les anomalies qui augmentent le temps de réponse consiste à :

1. Identifier pour chaque fonctionnalité du site les classes utilisées, leurs interactions mutuelles et leur ordonnancement dans le temps (les diagrammes de séquence d’UML sont particulièrement adaptés pour schématiser ce genre d’interactions).

2. Chronométrer le temps nécessaire pour l’instanciation des dites classes et l’appel de leurs interfaces. (Les interfaces dont il est question ici sont les méthodes et les propriétés des classes. Pour éviter toute confusion, les classes d’interface seront dorénavant désignées par des majuscules).

3. Repérer, sur cette base, les impasses et les goulots d’étranglement (c’est à dire les classes dont l’instanciation ou les interfaces provoquent un blocage ou exposent un temps de réponse anormalement long).

4. Analyser le code encapsulé dans lesdites classes pour relever les anomalies qui compromettent la performance.

La technique expliquée dans cet article consiste en l’injection d’un compteur dans le code source des classes dont on souhaite mesurer la performance . Le compteur en question ne doit pas consommer plus de 1% du temps requis pour l’exécution des opérations auxquelles il est associé. Dans le cas contraire, le recours à cette technique doit être remis en cause surtout dans les applications fortement distribuées. Pour notre part, nous recommandons l’utilisation du compteur System.currentTimeMillis()parce que son exécution sur un PC standard consomme moins de 0.5 milliseconde.

Télécharger la suite de l’article au format pdf

Figure 8: Exemple d’une segmentation en fonction des composants de l’application [1]

Notes de bas de page

[1] Source: Diagnosing J2EE performance problems throughout the application life cycle. MERCURY INTERACTIVE