Les goulots de performances peuvent aisément être identifiés à l'aide des vues statistiques. Cette rubrique décrit un scénario permettant d'améliorer le temps d'exécution. La vue Statistiques de packages est un point de départ convenable car elle identifie les packages responsables du ralentissement du temps d'exécution. A partir de là, vous pouvez rechercher la classe ou la méthode responsable des performances d'exécution médiocres.
Lors du lancement de l'application à profiler, activez la collecte des informations de flux d'exécution. (Sélectionnez l'option de profilage Mon application est trop lente puis, dans les options Détails, sélectionnez Afficher les détails graphiques de flux.)
Une fois ouverte, la vue Statistiques de package est similaire à la suivante :
Cette vue affiche les statistiques des classes différentes, regroupées par les packages qu'elles contiennent. La vue peut être personnalisée de sorte qu'elle affiche tous les types de données statistiques, par exemple, des statistiques de temps et d'allocation de mémoire. Dans le présent cas, assurez-vous que les colonnes de temps s'affichent car elles contiennent les informations requises. (Cliquez à l'aide du bouton droit de la souris, sélectionnez Sélectionner des colonnes, puis configurez ces colonnes de sorte qu'elles soient visibles.) Vous pouvez également trier les packages à l'aide de la colonne Heure de base de l'exécution. Comme indiqué ci-dessus, le package com.ibm.ws.ejbpersistence.dataaccess correspond au
"point d'ancrage" de l'exécution et, dans ce package, la classe DataAccessRequestImpl est responsable du ralentissement du temps d'exécution.
A présent, il est claire que la méthode execute est responsable des performances médiocres de la classe DataAccessRequestImpl ; son temps d'exécution est très élevé par rapport au temps passé dans l'autre méthode, executeOneRowFBPK.
Observons de près la vue Statistiques de classes. Il est à noter que la classe java.text.NumberFormat est la suivante dans la liste des classes responsables du ralentissement du temps d'exécution. En particulier, java.text.NumberFormat.getCurrencyInstance() consomme le temps passé dans cette classe. Cela donne une idée du résultat de l'utilisation des méthodes apparemment simples. Même si NumberFormat.getCurrencyInstance() semble être une API simple, l'appel de cette dernière à plusieurs reprises peut avoir un grand impact sur les performances globales de l'application.
A présent, étudions les appels de la méthode DataAccessRequestImpl.execute(). Une des fonctions puissantes de l'outil de profilage est la représentation graphique de l'exécution de l'application, ce qui permet de visualiser l'exécution de méthode au niveau d'appel de méthode. Cette vue est utile car elle affiche le modèle d'exécution et les différences entre les appels de la même méthode. Voici la vue Appel de méthode qui illustre l'appel de la méthode DataAccessRequestImpl.execute().Dans ce graphique, vous pouvez identifier l'élément qui a appelé cet appel dans la pile d'exécution ou vous pouvez passer au code source de la méthode. Vous pouvez également visualiser le temps passé, en déplaçant le curseur sur n'importe quelle barre.
La table Appel de méthode ci-dessous affiche les mêmes appels de méthode, mais au format tabulaire. Il est à noter que, pour le premier appel de méthode, le temps d'exécution (voir la colonne Heure cumulée) est très élevé par rapport aux appels de méthode ultérieurs.
Il en résulte que la méthode responsable du ralentissement du temps d'exécution global correspond au premier appel de la méthode OnlineItembean.FindByValue.
Concepts connexes
Présentation de l'outil de profilage
Tâches connexes
Profilage d'une application
Lancement ou association d'un processus Java
(C) Copyright IBM Corporation 2000, 2003. All Rights Reserved.