Une demande de connexion non groupée est assez lourde: vous devez créer une nouvelle connexion, l'utiliser et la fermer. Un pool de connexions élimine la majeure partie de ce surcoût, car la plupart des requêtes n'entraînent pas le coût de création d'une connexion (la partie la plus lourde de la gestion des connexions) ou le coût de sa fermeture. Cependant, chaque demande à la base de données utilisera une connexion (donc votre 2ème mise à jour utilise certainement une connexion). Tout ce que le pool fait est de créer les connexions pour vous en votre nom, et vous permet de les réutiliser - donc la "connexion à la base de données" et la "connexion au pool" sont vraiment la même chose.
Généralement, vous configurez un pool avec un nombre minimum de connexions. Par exemple, vous pouvez le configurer pour toujours avoir au moins cinq connexions. Lorsque votre application démarre, le pool alloue ces connexions avant que les demandes ne soient reçues. Lorsque chaque requête arrive, le pool prête une connexion déjà ouverte pour être utilisée par la requête. Une fois la connexion effectuée, elle doit être renvoyée dans le pool par le code qui l'a emprunté. Si votre application a de nombreuses demandes simultanées, vous pouvez manquer de connexions. C'est là qu'interviennent d'autres stratégies sur le pool de connexions.
Il existe généralement un paramètre pour ce qu'il faut faire lorsque vous êtes à court de connexions (toutes les connexions sont prêtées à des demandes), par exemple «créer 1 connexion de plus» ou « créer 5 autres connexions ". Ainsi, s'il n'y a que 5 connexions groupées et qu'une sixième demande simultanée arrive, il y aura probablement des coûts encourus pendant que le pool crée une ou plusieurs connexions supplémentaires.Cependant, une fois créé, vous avez maintenant une piscine qui a grandi pour accommoder rapidement un plus grand nombre de connexions pour une période occupée. De même, si le nombre de demandes arrivées a ralenti (peut-être la nuit), vous pourriez avoir un tas de connexions inactives dans le pool. Les pools ont généralement une politique configurable pour ce qu'il faut faire avec les connexions inactives. Par exemple, vous pouvez dire que vous voulez seulement au plus 5 connexions inactives dans le pool et vous considérez une connexion "inactive" si elle n'a pas été utilisée dans les 5 dernières minutes. Le pool ferme alors les connexions pour réduire la taille du pool à une taille plus petite, libérant ainsi des ressources inutiles.
Une autre politique que vous pouvez définir est le nombre maximum de connexions que le pool est autorisé à avoir. Dans votre exemple, vous avez cette valeur à 8. Cela signifie que quelle que soit l'intensité de votre application, vous n'autoriserez jamais plus de 8 requêtes de base de données simultanées. C'est ici qu'intervient une autre politique: que faire lorsque vous n'avez plus de connexions et n'êtes pas autorisé à développer le pool? Généralement, un pool fournit plusieurs choix, par exemple "attendre une connexion libre", "faire plus de connexions", "lancer une exception", etc. Comme votre exemple a un "max wait" de -1, cela doit signifier le défaut de votre pool doit attendre une connexion aussi longtemps que nécessaire (en supposant que -1 signifie "pour toujours"). Selon votre application, cela peut être un bon ou un mauvais choix. En général, je pense qu'au fil du temps, vous surveillez la durée des demandes, le nombre de connexions que vous avez à la fois, etc. et modifiez vos paramètres de pool pour qu'ils soient les plus efficaces, c'est-à-dire, réduisez le temps d'attente. connexion, réduisez le nombre de ressources allouées aux connexions et réagissez rapidement aux modifications des modèles de requête. Enfin, en ce qui concerne votre question, vous pouvez avoir 0 connexions actives et 0 actives si votre pool est configuré pour fermer les connexions de manière agressive. Essayez de définir la taille minimale du pool pour l'augmenter.