Stratégies pour l'analyse d'une nouvelle application Java
Voici des scénarios et des paramètres à modifier lors de la création qui peuvent vous aider à bénéficier de l'expérience et des données d'analyse qui sont particulièrement utiles pour vous.
Analyse d'une nouvelle application pour laquelle l'administrateur a très peu de connaissances
Accepter tous les paramètres par défaut peut être une bonne façon de démarrer l'analyse d'une application pour laquelle l'administrateur a très peu ou aucune connaissance. Après avoir analysé tous les paramètres par défaut pendant un certain temps, l'administrateur peut commencer à régler des paramètres en fonction des alertes d'analyse, des données Application Diagnostics et des rapports Application Advisor. Pour plus d'informations, voir Procédure d'analyse des applications Java.
Limiter l'analyse à un ensemble spécifique de serveurs
La définition d'un groupe ciblé vous permet de limiter l'analyse à un ensemble spécifique de serveurs. Pour les déploiements d'application très volumineux, il est en général inutile d'analyser toutes les instances de l'application. Un échantillon représentatif est suffisant pour obtenir les données dont vous avez besoin. En utilisant uniquement un échantillon représentatif, la quantité de données collectées et stockées sera moindre.
Réduire le « bruit » en définissant la quantité de données collectées
L'augmentation du seuil de sensibilité vous permet de filtrer les méthodes d'exécution rapide, ce qui réduit le « bruit » global, ou la profondeur de la pile d'appels. Vous pouvez ainsi déterminer plus facilement l'emplacement du problème. Cela réduit également la bande passante réseau.
Le paramètre de sensibilité est utilisé pour déterminer si un appel de fonction doit être inclus dans la pile d'appels. Toute fonction qui s'exécute et est renvoyée plus rapidement que le niveau de sensibilité est abandonnée, ce qui empêche les petites fonctions d'exécution rapide de masquer le problème réel. Gardez en mémoire que l'utilisation de la sensibilité réduit uniquement le nombre de fonctions indiquées dans la pile d'appels pour des événements spécifiques. Un événement sera toujours généré si le seuil global est dépassé.
Vous pouvez régler le seuil de sensibilité dans le fichier de configuration comme indiqué dans le guide du pack d'administration d'analyse des performances des applications Java.
Il est également possible pour une sensibilité élevée de masquer les problèmes. Dans le cas où une fonction appelle une autre fonction, si le temps de réponse de l'appelé augmente même légèrement, cela peut engendrer des problèmes pour l'application. Par exemple, si vous avez une fonction de traitement des données qui appelle une fonction de recherche 1 000 fois et que le temps de traitement de la recherche augmente de 1 ms, vous augmenterez le temps de réponse de votre fonction supérieure d'une seconde complète. Ceci peut être masqué par la sensibilité élevée. Lorsque vous rencontrez ce genre de situation, vous pouvez ajouter l'appelé sous forme de méthode et lui définir une sensibilité personnalisée afin de vous assurer qu'il est toujours mesuré en fonction du seuil de sensibilité inférieur.
Les alertes de défaillance de l'application sont des échecs d'application, ou de code, qui sont détectés au sein de l'application. Vous pouvez choisir de ne pas recevoir les alertes de défaillance de l'application, ce qui se produira potentiellement très souvent si une application a des problèmes car ces types d'alertes requièrent généralement des modifications de code. Cette désactivation permet de réduire le « bruit » de nombreuses alertes déclenchées et qui ne peuvent pas être résolues directement par l'équipe des opérations.