2017-05-10 4 views
1

De nombreux serveurs d'applications ont des pools de connexion intégré, et même des applications autonomes peuvent être configurés pour un comme HikariCP, Apache DBCP, etc.Avantage de PgBouncer avec le pool de connexions WildFly/Application Server?

Alors, quel est l'avantage d'utiliser pgbouncer lorsque l'application a déjà un pool de connexion?

La réponse la plus proche que j'ai trouvée est What are advantages of using transaction pooling with pgbouncer? qui ne mentionne pas l'utilisation d'un autre pool de connexions et mentionne que l'avantage est l'utilisation des sessions inactives. L'utilisation principale WildFly est configurée avec une taille de pool minimale, une taille de pool max, un délai d'inactivité ... donc elle supprime essentiellement les connexions inactives lorsqu'elles ne sont pas utilisées (si c'est l'avantage principal). Cela me fait penser que PgBouncer ne rentre pas dans ce scénario et que je devrais continuer à utiliser mon pool de connexions au serveur d'applications uniquement. BTW, en mode de regroupement de transactions, PgBouncer ne peut pas utiliser les instructions préparées nommées qui ne ressemblent pas à un choix de performances.

S'il y a un avantage, cela fonctionne-t-il bien avec le pool de connexion wildfly?

+1

pgBouncer est généralement utilisé lorsque vous souhaitez également équilibrer la charge entre un serveur maître et un serveur esclave. Si vous ne vous connectez qu'à un seul serveur Postgres, alors un pool de connexion dans le serveur d'applications est suffisant –

Répondre

0

Si votre pool d'applications comporte un pool de connexions et qu'un seul serveur d'applications se connecte à la base de données, il est préférable d'utiliser le pool de connexions intégré. Dans un tel scénario, pgBouncer serait simplement un composant supplémentaire qui rendrait l'architecture plus compliquée, et vous auriez le surcoût de toutes les connexions entre le serveur d'applications et pgBouncer.

Si plusieurs serveurs d'applications se connectent à la même base de données, la question n'est plus aussi simple. S'il n'y a que deux ou trois serveurs d'application, vous pourriez bien vivre sans pgBouncer. Plus les serveurs d'applications se connectent au serveur de base de données, plus vous aurez de connexions à la base de données, ce qui met la base de données en péril: si trop de ces connexions sont occupées en même temps, les performances et le temps de réponse de votre base de données drop, car la base de données est surchargée. Dans ce cas pgBouncer aidera en limitant le nombre de connexions actives à la base de données.

+0

Oui, mais cela ne répond pas à ma question, supposons que j'ai 2 ou 3 serveurs d'applications connectés à la base de données (c'est plus facile de grouper l'application que le db), je ne vois toujours pas l'avantage d'utiliser PgBouncer comme vous l'avez dit c'est juste un composant supplémentaire qui rend l'architecture plus complexe. – JorSol

+0

Vous n'avez pas dit que vous avez plusieurs serveurs d'applications. Je vais modifier la réponse pour commenter cela. –

+0

Merci pour l'édition Laurenz, mais encore ne pas obtenir l'avantage, je peux limiter le nombre maximum de connexions dans le pool de connexions app-serveur, donc je ne vois pas comment cela met la base de données à risque, peut-être si Je démarre dynamiquement les serveurs d'applications en fonction de la charge? Et encore une fois, la meilleure fonctionnalité est "Mise en commun des transactions", qui devrait être testée avec soin car elle peut casser beaucoup de choses liées à la session, et elle perd les instructions préparées nommées. – JorSol