HikariCPがパフォーマンスを向上させるために固定サイズのプールを推奨するのはなぜですか
HikariCPのドキュメントによると、パフォーマンスを向上させるために固定サイズのプールを作成することに言及しています。
minimumIdle：
このプロパティは、HikariCPがプール内で維持しようとするアイドル接続の最小数を制御します。アイドル接続がこの値を下回った場合、HikariCPは接続を迅速かつ効率的に追加するために最善を尽くします。ただし、最大パフォーマンスおよびスパイク要求への応答性については、この値を設定せず、代わりにHikariCPを固定サイズの接続プールとして機能させることをお勧めします。デフォルト：
maximumPoolSizeと同じ
私のアプリケーションは通常100の接続を必要とし、ごくわずかな状況でのみ200の接続に達します。
200接続の固定サイズのプールを作成すると、ほとんどの場合、100接続がアイドル状態になります。
したがって、次のうちどれが最適ですか。
- 固定サイズで接続プールを作成します。つまり200
[〜＃〜]または[〜＃〜]
minimumIdleを100に、maximumPoolSizeを200に設定して、接続プールを作成します。
なぜ2番目のポイントがHikariCPによって推奨されないのですか？私の場合は2番目が最適だと思います。
私はあなたに提案します これを読んでください ページと添付のビデオを見てください。 Oracle Performance Groupは、96の接続のプールを持つアプリケーションが、10,000のフロントエンドユーザーと毎秒20,000のトランザクションを簡単に処理する方法を示しています。
PostgreSQLでは次の式を推奨しています。
connections = ((core_count * 2) + effective_spindle_count)
どこ core_countはCPUコアであり、effective_spindle_countは、RAID内のディスクの数です。多くのサーバーでは、この式により、最大接続数が10〜20の接続プールが生成されます。
100の接続でも、データベースが大幅に飽和状態になっている可能性があります。 50個のCPUコアがありますか？ドライブがSSDではなくプラッターを回転させている場合、ヘッドは一度に1つの場所にしか配置できません。データセット全体がメモリ内にない限り、一度に多くの要求（100〜200）を処理する方法はありません。
更新：固定プールのサイズ設定に関する質問に直接回答します。 DBが処理できる「ニー」または「ピーク」パフォーマンスで最大接続数が右に曲がるプールを使用すると、アプリケーションから最高のパフォーマンスが得られる可能性があります。これはおそらく少数です。多くのアプリケーションがそうであるように、「スパイク需要」がある場合、スパイクの瞬間にプールを拡大するために新しい接続をスピンアップしようとすると、逆効果になります（moreサーバーにロード）。小さくて一定のプールは、予測可能なパフォーマンスを提供します。
これは、実行時間の長いトランザクションと実行時間の短いトランザクションを実行するアプリケーションの動作に実際に依存します。クライアントの同期方式に応答したい場合は、プールへのアイドル接続を保持する方がよいと感じることがあります。