Monitoring : StackProbe : Un Profiler Java efficace, permet de comprendre ce qui se passe dans la JVM et exploite JMX

StackProbe est un outil pour la surveillance des applications Java: Il vous aide à trouver des fuites de mémoire et d'optimiser la vitesse.

Nécessite d’un profiler

Savoir ce qui se passe dans une application Java EE n’est pas chose facile, surtout lorsqu’on qu’on en dispose des documents d’architecture ni de la description de la structure des codes sources.

Mais, dans la majorité des situations, qu’on dispose du code source ou non, on a besoin d’inspecter ce qui ce passe réellement dans la JVM, qu’est ce qui se passe dans la JVM.

Un Profiler JVM est une solution de surveillance des applications Java qui vous permet de détecter, d'isoler et de diagnostiquer (d’une façon pro active) les problèmes de performance.

VisualVM, intègre à Java 6 de Sun, permet de savoir quelques informations.

NetBeans offre un profiler de qualité, et Eclipse n’arrive pas à simplifier l’installation de son TPTP.

Les outils commerciaux CA Wily Introscope ou ceux de HP Mercury sont légende dans la profession,

L’outil JProfiler est extrêmement populaire, mais nécessite d’être installé.

Mais, cette fois je présente un autre produit plus simple, sans installation : stackProbe

installer stackProbe

stackProbe est capable de profiler toute application java tournant sous le JDK 6.x de SUN.

Il suffit de le télécharger stackprobe.jar (120 kB !! ) et de lancer dans une JVM

java -jar stackprobe.jar

bien sûre après avoir obtenu une licence (StackProbe est un profiler commercial, il est gratuit pour les projets open source)

Il est possible de l’utiliser avec le service JNLP, ce qui permet d’utiliser toujours la dernière version stable disponible.

Le profiler : StackProbe

Il s’agit d’une inspection minutieuse de l’intérieur de la JVM.

Exemple : présentation des activités de Thread

Utiliser des filtres de type:

Présentation des activités des méthodes : on est capable de choisir le package pour isoler

• Thread-[0-9]+ pour "Thread-1", "Thread-2", ….
• com\.oxia\..* n’importe quelle méthode du package "com.oxia".

Présentation des résultats en suivant le chemin d’appelle des méthodes

Méthode : StackProbe utilise la méthode de sampling

StackProbe utilise la méthode de sampling, alors que la majorité des autres profiler utilisent l’instrumentation de bytecode.

Comment ça fonctionne :

StackProbe demande périodiquement à la JVM la liste des StackTraces pour tous les threads. Ces listes sont appelées échantillons. Plus l’application passe de temps dans une méthode, plus elle sera présente dans l’échantillonnage.

Le principal avantage de cette technique est que, même si elle présente une perturbation, cette surcharge est réparti également entre toutes les méthodes de l'application observée, il n'ya donc pas de risque d'introduction de faux goulets d'étranglement.

Le Profiler offre un panneau de paramétrages qui vous permet de régler le profilage à vos besoins.

L’avantage de StackProbe, c‘est qu’il n’a pas besoin d’être installé et il est capable d’inspecter la JVM sans instrumenter le code de l’application.

StackProbe ne fait pas la Détection et résolution de problèmes

Ce profiling, doit être intégré dès les premières phases d’un projet, ce qui permet d’anticiper les problèmes

Ce type outil doit être mis à la disposition de tous les développeurs et de l’équipe système, il pemrt d’offrir les données pour

Détection des fuites mémoire

La fuite mémoire apparait lorsqu'un objet n'est plus utilisé mais reste actif et ne peut être nettoyé par le GC.

Rechercher & donner des solutions pour les goulots d'étranglement de performances

Détecter et identifier quelle portion de code génère des problèmes de performances n'est pas une tâche simple et rapide.

Détecter & résoudre des « Deadlock »

Le < deadlock > est une condition ou des threads sont bloquées en attente d'entrer dans un bloc de synchronisation ou lorsque deux ou plusieurs threads s'exécutent simultanément et attendent les mêmes ressources.

Détecter la mauvaise utilisation de la mémoire

Détecter les objets qui utilisent d'une façon anormale plus de mémoire que nécessaire, sans qu'il y ait de fuite mémoire. Cette situation entraine une consommation excessive de la mémoire et engendre des besoins importants de swap.

Malheureusement, ce travail de détective reste à votre charge.

La solution de Profiling idéale devrait apporter, automatiquement, des solutions aux problèmes de performances du code

Mais ceci est un autre sujet.

d’autres sujets :

autres sujets traités :

1. Est-ce que vous voulez connaitre ce que fait votre application coté base de données : employer un espion (open source)

2. Performance Engineering Process & Solutions (PEP&S) : Partie 2

3. La nouvelle version 3.0 de SOAPUI améliore le test des services REST

4. Performance Engineering Process & Solutions : PEP&S

5. Améliorer la performance de vos travaux de fin de journée par “JDBC Batch” et Spring

6. Application web : la différence entre Mesure de performance, montée en charge et vitesse d’exécution

7. Are the data from the GoogleApp Engine Dashbord valid?

8. Quel crédit donner aux résultats affichés par le DashBoard de GoogleApp Engine (GAE) ?

9. InfraRED : un outil de suivi des temps de réponse d’application J2EE, de monitoring et diagnostique de problèmes de performance.