> Data > Le gardien du .Net Connection pool

Le gardien du .Net Connection pool

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par William Vaughn - Mis en ligne le 02/02/2004 - Publié en Février 2004

Prévenez les débordements de pool qui pourraient noyer vos applications

La plupart des fournisseurs de données ADO.NET utilisent le connection pool, pour améliorer la performance des applications construites autour de l'architecture .NET déconnectée de Microsoft ...Une application ouvre une connexion (ou obtient un traitement de connexion de la part du pool), exécute une ou plusieurs requêtes, traite l'ensemble des lignes et libère la connexion pour la rendre au pool. Sans ce pooling, ces applications passeraient beaucoup plus de temps à  ouvrir et à  fermer des connexions.
Quand vous utilisez le connection pooling ADO.NET pour gérer les connexions des applications basées sur le Web et des applications de service Web client/serveur, vos clients obtiennent généralement des connexions plus rapides et de meilleures performances. Mais que se passe-t-il quand votre application ou votre site Web est soudain submergé par des clients tous désireux de se connecter en même temps? Votre application vat- elle couler ou nager ? Comme un gardien, vous devez surveiller de près vos connection pools pour maintenir un bon niveau de performance et pour empêcher tout débordement des pools. Voyons les raisons pour lesquelles un connection pool pourrait déborder, puis voyons comment écrire du code ou utiliser Windows Performance Monitor pour surveiller les pools.
Comme je l'expliquais dans l'article « Nager dans le .NET Connection Pool », SQL Server Magazine octobre 2003, vous devez connaître beaucoup de détails d'évolutivité et de performance quand vous utilisez le connection pooling. Souvenez-vous que vous devez surveiller et gérer deux aspects essentiels : le nombre de connexions gérés par chaque pool et le nombre de connection pools. Dans un bon système de production, le nombre de pools est généralement bas (de 1 à  10) et le nombre total de connexions en service est lui aussi bas (moins de 12). Il faut à  une requête efficace moins d'une seconde pour s'effectuer et se déconnecter. Ainsi, même si des centaines de clients accèdent en même temps à  votre site Web, une poignée de connexions peut généralement traiter toute la charge. Pour que vos applications fonctionnent efficacement, vous devez contrôler les ressources de connexion et surveiller l'état de vos pools afin d'être averti avant qu'ils ne débordent et que vos clients commencent à  se plaindre … ou à  aller voir ailleurs.

Les participants aux groupes de
discussion par e-mail se plaignent souvent du fait que les applications
semblent fonctionner lors des tests
mais échouent en production. Ils signalent
parfois que leurs applications
s’arrêtent ou saturent quand 100
clients environ sont connectés. Rappelons
que le nombre de connexions
par défaut dans un pool est de 100. Si
l’on essaie d’ouvrir plus de 100
connexions à  partir d’un pool, ADO.
NET met en file d’attente la demande
de connexion de votre application jusqu’à 
ce qu’une connexion soit libre.
L’application (et ses utilisateurs) voit
cela comme un retard dans l’obtention
de la page Web ou comme un blocage
de l’application. Voyons donc comment
ce problème survient.
Dans ADO.NET, le SqlClient .NET
Data Provider propose deux techniques
pour ouvrir et gérer les connexions.
Premièrement, quand vous
devez gérer la connexion manuellement,
vous pouvez utiliser l’objet
DataReader. Ce faisant, votre code
construit un objet SqlConnection,
définit la propriété ConnectionString,
et utilise la méthode Open pour ouvrir
une connexion. Quand le code en a fini
avec le DataReader, vous fermez la
SqlConnection avant que l’objet
SqlConnection soit hors de portée .
Pour traiter l’ensemble de lignes, vous
pouvez transmettre le DataReader à 
une autre routine de l’application,
mais il faudra quand même vous assurer
que le DataReader et sa connexion
sont fermés. Si vous ne fermez pas le
SqlConnection, votre code « laisse
fuir » une connexion avec chaque opération,
donc le pool accumule les
connexions, parfois jusqu’au débordement.
Contrairement à  ADO et Visual
Basic (VB) 6.0, le collecteur de .NET ne
ferme pas la SqlConnection et fait le
nettoyage. Le listing 1, que j’examinerai
plus loin, montre comment j’ai ouvert
une connexion et généré un
DataReader pour renvoyer l’ensemble
de lignes à  partir d’une simple requête
pour stresser le connection pool.
Vous risquez aussi des problèmes
quand vous utilisez l’objet DataAdapter.
Les méthodes DataAdapter Fill et
Update ouvrent automatiquement
la connexion de l’objet DataAdapter et
la ferment au terme de l’opération
d’I/O des données. Cependant, si la
connexion est déjà  ouverte quand la
méthode Fill ou Update est exécutée,
ADO.NET ne ferme pas le SqlConnection
à  la fin de la méthode. C’est encore
une autre occasion de laisser fuir
une connexion.
En outre, vous pouvez aussi utiliser
ADO basé sur COM pour créer une
connexion à  partir d’une application
.NET. ADO poole ses connexions de la
même manière que le fait ADO.NET
mais ne vous donne pas un moyen de
surveiller le pool à  partir de votre application,
comme vous le pouvez
quand vous utilisez le SqlClient ADO.
NET Provider.

Téléchargez gratuitement cette ressource

Guide PME : 5 leviers pour accélérer votre développement

Guide PME : 5 leviers pour accélérer votre développement

Grandir, se développer et piloter la croissance sont des enjeux majeurs pour les PME qui doivent sécuriser le quotidien pour s’engager vers demain. Découvrez, dans ce Guide infographique, les différents leviers qui vous permettront de consolider durablement votre développement.

Data - Par iTPro.fr - Publié le 24 juin 2010