Comment le pool de connexions à la base de données affecte les performances?

Question

J'utilise .Net 2.0 + SQL Server 2005 Enterprise + VSTS 2008 + C# + ADO.Net pour développer l'application Web ASP.Net. L'application Web ASP.Net est centrée sur la base de données/pilotée. Je veux savoir s'il existe des données de référence de performances sur les différences de performances lorsque nous activons/désactivons le paramètre de pool de threads dans le paramètre de chaîne de connexion ADO.Net? Performance Je veux dire à la fois la connexion simultanée qui pourrait être supportée et le temps d'exécution d'une commande SQL spécifique exécutée du côté client ADO.Net?

grâce à avdance, George

Answer 1

Je n'ai pas de statistiques de performance à portée de main, mais peut-être un mot d'avertissement lors de l'utilisation mise en commun de connexion: vous pourrait se retrouver avec trop de petites piscines, au lieu d'une grande.

ADO.NET va créer un nouveau pool de connexion pour

• chaque chaîne de connexion; très très difficile - si vous avez deux chaînes de connexion qui sont différentes même d'un seul espace ou quelque chose, elles sont considérées comme deux chaînes de connexion séparées et conduiront à créer des pools de connexion distincts

• pour chaque identification Windows si vous utilisez la « sécurité intégrée » (connexion approuvée) mise

donc, si vous avez une chaîne de connexion quelque chose comme

server=MyDBServer;database=MyDatabase;integrated security=SSPI; 

un pool de connexion pour chaque utilisateur identifiable sera créé - c'est plutôt contre-intuitif, mais c'est comme ça (et il ne peut pas être influencé/désactivé).

Consultez le MSDN docs sur ADO.mise en commun de connexion NET pour plus de détails:

Lorsqu'une connexion est d'abord ouverte, un pool de connexion est créé sur la base d'un algorithme de correspondance exacte que associe la piscine avec la chaîne de connexion dans la connexion. Chaque pool de connexions est associé à avec une chaîne de connexion distincte. Lorsqu'une nouvelle connexion est ouverte, si la chaîne de connexion n'est pas une correspondance exacte avec un pool existant, un nouveau pool est créé. Les connexions sont mises en commun par processus , par domaine d'application, par chaîne de connexion et lorsque la sécurité intégrée est utilisé, par identité de Windows . Les chaînes de connexion doivent également correspondre exactement à ; mots-clés fournis dans un ordre différent pour la même connexion seront regroupés séparément.

En outre, si vous avez ces deux chaînes de connexion:

server=MyDBServer;database=MyDatabase;user id=tom;pwd=top$secret 

et

server=MyDBServer;database=MyDatabase;user id=tom; pwd=top$secret; 

ceux-ci sont considérés comme différentes chaînes de connexion, et donc deux pools de connexion distincts seront créés.

Lorsque vous tentez de mesurer l'effet du regroupement de connexions, vous devez en être conscient!

Marc

Answer 2

La différence de performance va varier considérablement d'une application à, donc il n'y a pas de données sur ce type de gains vous devriez vous attendre.

Le meilleur plan d'action pour vous de le prendre à mesure en faisant des tests de résistance sur votre application avec elle configuré avec/sans pooling et voir comment il foires.

WCAT est un type d'outil de stress que vous pouvez utiliser pour charger votre application ASP.NET.

Vous pouvez également essayer un profileur (dont il existe de nombreux) pour surveiller votre application pour voir comment elle fonctionne sous le stress.

Quelques Profilers: ANTS, dotTrace

Answer 3

écrire un petit progeam pour accéder à la base de données. ouvrez la connexion à la base de données sans la fermer et bouclez 100 fois.

1. Surveillez le temps dont vous avez besoin pour obtenir les données à chaque fois.
2. Surveiller les connexions côté sever en utilisant « netstat »
3. avec/sans mise en commun

Answer 4

Vous dites « pool de threads », mais parlons évidemment de pool de connexion que vos émissions de titres.

Il existe un surcoût lié aux performances pour la création de nouvelles connexions de base de données. C'est une opération gourmande en ressources, c'est pourquoi nous avons le regroupement de connexions ADO.NET. Effectivement, les connexions ne sont pas fermées, mais simplement renvoyées au pool où elles restent actives et peuvent être réutilisées par d'autres parties de la même base de code (à l'intérieur de l'AppDomain). Un pool d'applications ADO.NET est créé pour une chaîne de connexion unique PER, il convient donc de noter que lorsque vous utilisez Integrated Security, vous perdrez les avantages du pool de connexions car vous disposerez effectivement d'un pool de connexions par utilisateur DB authentifié.