PgBouncerとWildFly/Application Serverの接続プールの利点？など

Question

多くのアプリケーションサーバで接続プールが統合されている、とさえスタンドアロンアプリケーションがHikariCP、ApacheのDBCPのような使用のいずれかに設定することができ、

だから、アプリケーションが既に接続プールを持っているときPgBouncerを使用する利点は何ですか？

最も近い答えはWhat are advantages of using transaction pooling with pgbouncer?で、別の接続プールの使用については言及せず、アイドルセッションの使用が利点であると述べています。

私は、最小プールサイズ、最大プールサイズ、アイドルタイムアウトで設定されたWildFlyを使用します。使用していないときにアイドル状態の接続を削除します（主な利点である場合）。

これは、このシナリオでPgBouncerが適合しないと思うので、アプリケーションサーバー接続プールのみを使用してください。

トランザクションプールモードでは、PgBouncerはパフォーマンス上の選択肢のようには見えない名前付きプリペアドステートメントを使用できません。

利点がある場合は、wildfly接続プールでうまくいきますか？

Answer 1

アプリケーションサーバーに接続プールがあり、データベースに接続するアプリケーションサーバーが1つしかない場合は、統合接続プールを使用することをお勧めします。

このようなシナリオでは、pgBouncerはアーキテクチャを複雑にする余分なコンポーネントにすぎず、アプリケーションサーバーとpgBouncer間のすべての接続に余分なオーバーヘッドがあります。

同じデータベースに接続する複数のアプリケーションサーバーがある場合、これ以上問題はありません。アプリケーションサーバーが2つか3つしかない場合は、pgBouncerなしで正常に稼動する可能性があります。

データベースサーバーに接続するアプリケーションサーバーが増えるほど、データベース接続が多くなり、データベースが危険にさらされます。これらの接続が同時に多すぎると、データベースのパフォーマンスと応答時間はデータベースがオーバーロードされているため、ドロップされます。 このような場合、pgBouncerはデータベースへのアクティブな接続の数を制限するのに役立ちます。