Création de stratégies pour l'analyse des applications .NET

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, consultez Comment faire pour démarrer une nouvelle Application de surveillance et Analyse des applications à l'aide des paramètres par défaut

La définition d'un groupe ciblé vous permet de limiter l'analyse à un ensemble spécifique de serveurs. Dans l'Assistant Analyse des performances des applications .NET, le groupe ciblé pour l'analyse côté serveur se trouve sur la page Éléments à analyser. Le groupe ciblé pour l'analyse côté client se trouve sur la page Activer l'analyse côté client. Si vous utilisez un groupe ciblé pour l'analyse côté client et un équilibrage de charge, consultez Analyse côté client avec des groupes ciblés et équilibreurs de charge

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.

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é pour l'analyse côté serveur et côté client indépendamment.

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.

Vous pouvez désactiver les alertes de défaillance de l'application pour l'analyse côté serveur et côté client indépendamment.

Par défaut, l'analyse des performances des applications .NET définit des exceptions critiques comme exceptions gérées par des gestionnaires d'exceptions spécifiques fournis par .NET Framework. Ces gestionnaires interceptent les exceptions ASP.NET de niveau supérieur et les exceptions de service Web que l'application analysée n'a pas pu intercepter et gérer en interne. En ajoutant des gestionnaires d'exceptions, vous ajoutez à la définition de l'analyse des applications ce qu'est une exception critique. En effet, toutes les exceptions gérées par ces fonctions seront considérées comme des exceptions critiques. En utilisant des gestionnaires d'exceptions, vous conservez l'avantage de la création de rapports rationalisée sur les exceptions critiques uniquement, mais vous avez l'avantage supplémentaire des fonctions de création de rapports qui vous intéressent. Pour plus d'informations et une liste des gestionnaires d'exceptions par défaut, consultez À l'aide de gestionnaires d'exceptions pour définir des Exceptions critiques.

Vous pouvez également régler le taux d'échantillonnage afin de contrôler l'impact sur les performances de l'analyse sur votre application avec l'analyse côté client. La réduction du taux d'échantillonnage réduit le trafic d'analyse de l'application et contribue à préserver les ressources du serveur. Si vous avez un site à faible trafic, l'instrumentation et la collecte des données de chaque utilisateur qui se connecte entraînent la nécessité de passer en revue une grande quantité de données ne pouvant pas donner lieu à une action. La prise d'un échantillon aléatoire vous donne une idée des performances des applications du point de vue du client sans vous surcharger d'une quantité importante de données à traiter et à stocker.