Surveiller le pool

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.

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.