besoin d'informations sur la création d'un pool de connexion dans la base de données (quelle que soit la base de données) et quelle est leur efficacité? Quelles sont les conditions où elles peuvent améliorer les performances.
Comment le créer explicitement?
7 Réponses :
La page INTRO à Apache DBCP résume bien:
créer une nouvelle connexion pour chaque l'utilisateur peut consommer du temps (souvent nécessitant plusieurs secondes d'horloge temps), afin d'effectuer une base de données transaction qui pourrait prendre millisecondes. Ouvrir une connexion par l'utilisateur peut être irréalisable dans un Application Internet accueillie publiquement où le nombre d'utilisateurs simultanés peut être très grand. Par conséquent, Les développeurs souhaitent souvent partager un "Pool" de connexions ouvertes entre tous des utilisateurs actuels de l'application. Le nombre d'utilisateurs réellement effectuer une demande à tout moment est généralement un très faible pourcentage de le nombre total d'utilisateurs actifs, et pendant le traitement de la demande est le seul temps qu'une connexion de base de données est obligatoire. La demande elle-même des journaux dans le SGBD et gère tout utilisateur Problèmes de compte en interne.
Quelle est leur efficacité? Dépend de la mise en œuvre. En règle générale, je m'attendrais à ce qu'une piscine instansible des connexions soit au démarrage, soit sur demande. La première connexion nécessitera une réelle connexion à la base de données, puis lorsque vous demandez une connexion, vous avez une connexion réalisée existante. La première demande de connexion prendra donc le plus de temps, et ensuite, vous tirez simplement des objets d'une collection (très rapide).
Étant donné que Sachin a spécifiquement demandé où les piscines peuvent adresser des performances, j'ajouterais qu'ils n'ont généralement aucun sens dans une application client-serveur, où vous avez moins de connexions que les utilisateurs. En particulier, ils n'auraient aucun sens dans une application épaisse client où vous avez un utilisateur qui se connecte à une base de données.
Créer des connexions aux bases de données sont des opérations très coûteuses. Les pools de connexion sont des instances de connexions de base de données créées et mises en cache. Chaque fois qu'une nouvelle connexion à une base de données est souhaitée, une nouvelle connexion est utilisée dans la piscine au lieu de créer une nouvelle connexion. Certaines plateformes telles que .NET + SQL Server utilisent des pools de connexion par défaut (vous n'avez pas besoin de créer le vôtre). Ainsi, ils améliorent fondamentalement les performances en enregistrant un temps de création de nouvelles connexions à chaque fois.
Utilisation d'un pool de connexion, vous gagnez du temps à chaque accès car la connexion est déjà établie.
De plus, au moins sur Oracle, vous gardez l'instruction compilée liée à la connexion, une exécution répétitive de la même instruction SQL est encore plus rapide.
(voir PrepondStatement si vous êtes en Java / JDBC)
Le seul risque de contre-performance est que lorsque vous gardez trop de connexions inactives dans votre piscine, les ressources associées (votre côté et sur la base de données) sont gaspillées.
N'oubliez pas que les connexions enferment également les ressources (threads, tampons) sur le serveur. Et une connexion établie est toujours authentifiée via une paire d'utilisateurs / mot de passe spécifique. Donc, si la mise en commun de la connexion ne fonctionne que lorsque toutes les connexions utilisent le même compte de base de données
Oui, vous avez totalement raison avec le problème unique du compte de base de données. (Cela peut être un problème lors de la migration d'une application C / S sur Web par exemple, si l'autorisation est en dB, en fonction de l'utilisateur connecté.)
Créer une connexion de base de données peut ne pas être une opération coûteuse, en fonction de votre environnement et de ce que vous avez l'intention de le faire.
Si vous allez exécuter une seule requête très simple, la connexion prend probablement aussi de long (ou plus longtemps) que la requête.
Certaines bases de données ont une connexion beaucoup plus grande que d'autres; Si elle est correctement accordée, MySQL devrait avoir très peu (au-dessus du temps pour créer une connexion TCP et faire la poignée de main du protocole). Cependant, si la latence à votre serveur est très élevée, même cela peut être assez important (en particulier si vous avez l'intention de ne faire que quelques requêtes).
Si vous prévoyez de faire, disons, 100 requêtes, ou quelques requêtes vraiment lentes, le temps de connexion disparaît dans l'insignifiance.
En règle générale, je dirais ouvrir une nouvelle connexion à chaque fois jusqu'à ce que vous puissiez démontrer que c'est un problème de performance réel. L'utilisation de la mise en commun de la connexion peut conduire à des bugs, ce que nous n'aimons pas:
Pour un environnement Web, vous ne voulez vraiment pas avoir une connexion (à partir d'une piscine ou autre) au début d'une requête, effectuez des centaines de questions, puis fermez-la. Cela verrouille efficacement votre connexion (qui est une ressource limitée du côté de la base de données) et limite donc le nombre d'utilisateurs que votre site Web peut prendre en charge. Bien mieux de prendre de la piscine, d'utiliser, de remettre en piscine (avant tout code qui prend beaucoup de temps). Considérant que les pools de connexion à la prise en charge sont quelques lignes de code (une fois que dans votre classe d'utilitaire de DataSource Manager), il n'y a aucune excuse pour ne pas les utiliser.
aperçu de bonecP ( http://jolbox.com ) dans la section de référence pour certains chiffres. N'oubliez pas que les systémoins etc. sont liées à une connexion afin que vous aurez besoin de les préparer à nouveau et à nouveau si vous traitez de connexions vous-même (un pool de connexion se cache également ceux pour vous).
Ma meilleure solution jusqu'à présent: utilisez une lazydatasource qui ne vous donne qu'une connexion lorsque vous en avez vraiment besoin (c'est-à-dire non aveuglément - si les données peuvent provenir d'un cache, vous pouvez éviter la base de données)
Votre question est un peu ambiguë:
Voulez-vous HomeGrow em> une implémentation de pool de connexion? Si tel est le cas, c'est un bon point de départ: http: //java.sun .com / Developer / OnlineTraning / Programmation / JDCBook / Conpool.html mais strong> Ceci est très découragé pour les environnements de production. Mieux vaut utiliser une API de mise en commun de la connexion existante et minutieusement testée, comme DBCP ou C3P0 . p> ou voulez-vous savoir comment utiliser em> un pool de connexion? Si tel est le cas, la réponse dépend de la connexion API de mise en commun de la connexion que vous utilisez. Il est heureusement disponible sur le site Web de l'API en question. P> ou voulez-vous savoir quand / pourquoi em> utiliser un pool de connexion? Si tel est le cas, cela améliorera sûrement les performances de connexion si vous avez une application de longue date (par exemple une application WebApplication) et vous devez connecter la base de données plus que souvent. La pratique JDBC normale est nommément: Acquérir code>, instruction code> et RESUNTSET code> dans le le plus court strong> Portée possible (c'est-à-dire à l'intérieur du même bloc de méthode). Parce que la connexion est assez chère et peut prendre jusqu'à 200 ms de temps, voire plus, l'utilisation d'un pool de connexion est beaucoup plus rapide. Il donne des connexions à la demande et prend soin de la fermeture de la connexion. Cela ne signifie toutefois pas que vous pouvez changer votre façon d'écrire JDBC, vous devez toujours les acquérir et les fermer dans la portée plus courte possible. La seule chose que vous devez changer est la façon dont vous acquérez la connexion. Par exemple. Changement de P> connection = connectionPool.getConnection();
Création de la piscine de connexion de base de données à l'aide de tomcat fort> Mettez les entrées de ressources dans context.xml Fichier: EM> P> Connection con= QuoteConnectionFactory.getInstance(). getConnection("jndiName");