> Tech > Surveiller le pool

Surveiller le pool

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Vous avez donc ouvert et fermé une connexion et vous voulez maintenant savoir si la connexion est encore en place. Plusieurs techniques permettent de déterminer le nombre de connexions encore ouvertes et ce qu'elles font :

  • Exécuter sp_who ou sp_who2. Ces procédures stockées du système renvoient l'information contenue

dans la table
système sysprocesses qui montre l’état de tous les processus
en cours et renseigne à  leur propos. Généralement,
vous verrez un SPID (server process ID) par connexion. Si
vous avez nommé votre connexion en utilisant l’argument
Application Name dans la chaîne de connexion, il sera facile
de trouver les connexions qui fonctionnent.

  • Utiliser SQL Server Profiler avec le modèle SQL-Profiler
    TSQL_Replay pour suivre la trace des connexions ouvertes. Si vous connaissez bien Profiler, cette méthode est plus
    simple que le polling en utilisant sp_who.

  • Utiliser le Performance Monitor pour surveiller les pools et
    les connexions. J’explique cette méthode plus loin.

  • Superviser les compteurs de performance dans le code.
    Vous pouvez surveiller l’état de santé du connection pool
    et le nombre de connexions établies en utilisant des routines
    pour extraire les compteurs ou en utilisant les
    contrôles .NET PerformanceCounter. Les deux techniques
    se trouvent dans les applications exemples que vous pouvez
    télécharger à  l’adresse http://www. itpro.fr.
  • Voyons comment
    trouver les compteurs
    de connection pool et
    comment utiliser ces
    méthodes de surveillance.

    Où se trouvent les
    compteurs de connection
    pool ?

    Pour superviser
    les compteurs de connection
    pool, vous devez
    surveiller le système
    où ADO.NET les crée et
    les incrémente. ADO.
    NET ne crée pas toujours
    un port sur le serveur
    Microsoft IIS ou le
    serveur SQL Server si
    vous vous connectez à 
    partir d’un système distant
    ; il crée les pools sur
    le système où s’exécute
    le code ADO.NET. Ce peut être un système Windows ou médian
    distant utilisant IIS, une application Web, ou un service
    Web. A l’inverse, les compteurs de performance de SQL
    Server sont sur le système SQL Server – et pas sur le client.

    Utiliser Performance Monitor pour superviser les pools.
    Si
    vous utilisez le snap-in Microsoft Management Console
    (MMC) Windows 2000 System Monitor, vous pouvez représenter
    graphiquement les compteurs SQL client en sélectionnant
    .NET CLR Data dans la liste déroulante Performance
    object, de la figure 1. A noter que vous pouvez superviser
    tous les processus en sélectionnant les instances _global_
    counter, ou bien examiner une instance spécifique –
    chaque pool engendre son propre jeu de compteurs.
    Performance Monitor dresse la liste de ces compteurs et les
    expose comme instances de l’objet de performances sélectionné.
    Mais Performance Monitor n’expose ces compteurs
    que s’il y a des instances à  superviser. Ainsi, la figure 1
    montre l’objet de performance .NET CLR Data mais aucune
    instance spécifique n’est listée. Cela signifie que vous devez
    créer au moins une connexion pour que la _global_instance
    apparaisse accompagnée d’une instance spécifique pour
    chaque processus. Ce comportement pose un problème à 
    votre code : vous ne pourrez utiliser le contrôle Performance
    Counter pour renvoyer certains de ces compteurs que
    quand ADO.NET les aura créés quand il ouvrira la connexion.
    C’est un peu un cercle vicieux. Le manque d’instances de
    compteur valide causera des exceptions quand vous utiliserez
    cette méthode – préparez-vous simplement à  les intercepter.Vous pouvez aussi superviser le nombre de connexions
    ouvertes en utilisant le compteur de performances SQL
    Server User Connections. Ce compteur apparaît sous SQL
    Server: General Statistics dans la liste déroulante
    Performance object. J’aime superviser la valeur de User
    Connections et certains compteurs .NET CLR Data SqlClient
    sélectionnés (que je décrirai plus loin) parce que je peux
    obtenir l’information qui m’intéresse sans me soucier des
    instances.

    Utiliser du code pour superviser les compteurs de performances.
    Quand vous avez besoin de superviser le connection
    pool programmatiquement, vous pouvez écrire du code
    pour superviser les compteurs de performances gérés par
    SqlClient – les mêmes compteurs que le snap-in MMC
    Windows NT Performance Monitor expose. Ecrire le code
    chargé de la supervision n’est pas une mince affaire.
    Mais j’ai inclus un instantané de la routine qui extrait ces compteurs des entrailles du provider
    SqlClient comme l’un des programmes
    téléchargeables inclus avec cet article.
    Vous pouvez écrire du code qui
    examine les cinq compteurs du tableau
    2
    . Ces cinq compteurs vous permettent
    de superviser le connection pool
    en temps réel. .NET s’attend à  ce que
    vous fournissiez une catégorie – dite
    Per f o rmance Object dans le
    Performance Monitor – et que vous sélectionniez
    les compteurs appropriés
    parmi ceux qui sont enregistrés auprès
    du système. Pour accéder aux compteurs
    SqlClient, mettez la catégorie à 
    .NET CLR Data.

    Utiliser les contrôles Performance
    Counter.

    Vous trouverez peut-être plus
    facile d’ajouter un Performance Counter
    à  votre formulaire d’application au
    moment de la conception, que de coder
    à  la main l’accès aux compteurs de
    performances. Pour cela, sélectionnez
    un PerformanceCounter dans le menu
    Visual Studio .NET Toolbox Components,
    faites-le glisser jusqu’à  votre formulaire
    d’application et définissez les
    propriétés comme en figure 2. Ces
    contrôles fonctionnent dans des formulaires
    Web et dans des applications
    WinForms.
    Comme le contrôle Performance
    Counter expose des listes déroulantes
    pratiques, vous pouvez voir les catégories
    de compteurs de performances,
    les noms de compteurs et les instances
    spécifiques au moment de la conception
    – sauf l’instance que vous êtes sur
    le point d’exécuter. Par conséquent,
    vous devrez recourir à  la technique de
    la figure 2 pour capturer l’instance appropriée
    du pool que votre application
    est en train d’utiliser. Pour contourner
    ce problème, je sélectionne la _global_
    instance. A nouveau, cette technique
    suppose qu’une application
    donnée a déjà  créé au moins un pool,
    et donc vous devez vous attendre à 
    voir ADO.NET émettre une exception
    quand il n’existe pas d’instances de
    compteur, tout comme il le fait quand
    il n’existe pas de connexions poolées.

    Attention au comptage de pools inexacts.
    A cause d’un bogue dans le
    SqlClient .NET Data Provider qui
    n’était pas corrigé dans .NET Framework
    1.1, les compteurs de performances
    indiquent à  tort que des pools
    restent « actifs » alors qu’en réalité ils
    ont été supprimés. J’ai pu vérifier que
    les pools n’existaient plus en finissant
    le snap-in MMC Performance Monitor,
    puis en finissant Visual Studio .NET.
    Ces étapes m’ont montré que le .NET
    Data Provider a bien supprimé les
    connection pools quand le processus
    qui les a créés s’est lui-même fini. A
    l’évidence, cette inexactitude réduit
    l’utilité des compteurs de performances
    pour superviser les pools, mais
    j’espère que Microsoft résoudra ce
    problème à  l’avenir.

    Téléchargez cette ressource

    Comment sécuriser une PME avec l’approche par les risques ?

    Comment sécuriser une PME avec l’approche par les risques ?

    Disposant de moyens financiers et humains contraints, les PME éprouvent des difficultés à mettre en place une véritable stratégie de cybersécurité. Opérateur de services et d’infrastructures, Naitways leur propose une approche pragmatique de sécurité « by design » en priorisant les risques auxquelles elles sont confrontées.

    Tech - Par Renaud ROSSET - Publié le 24 juin 2010