コネクションプール（connection pool）について

今回は、IT関連の動画を見ていたときに知らないところもあったので、コネクションプールについて整理していきたいと思います。

間違っている部分がありましたら、ぜひコメントをお願いいたします。

コネクションプール（connection pool）とは

WEBコンテナ（WAS、Web Application Service）が実行される時に一定のConnectionオブジェクトを前もって生成してPoolに保存します。

クライアントからリクエストが受け取ったらコネクションプールはConnectionオブジェクトを提供し、クライアントは借りたオブジェクトの使用が終わったらConnectionオブジェクトを返却し、そのオブジェクトをコネクションプールはまた保存します。

こういった機能のことをコネクションプール（DBCP）といいます。

DB接続の設定オブジェクトを前もって生成し、接続したらメモリ上に登録しておくので、不必要な作業（コネクションの生成や削除）がなくなる、つまりクライアントがDB接続にて時間短縮ができます。
DBコネクションの数を制限できるため、過度なアクセスによるサーバ資源がなくなることを防ぐことができます。
DBアクセスモジュールを共通化し、DBサーバの環境が変わった時に保守がしやすいです。
接続が終わったコネクションを再利用できるので、新しいオブジェクトの生成費用を抑えられます。

あまりにも多いDBアクセスが発生する場合はコネクションが限定されているため、利用できるコネクションが返却されるまで待たなければならないです。

なお、あまりにも多いコネクションを生成するとコネクションもオブジェクトなのでメモリ上で割り付けられます、つまりプログラムの性能が落ちる原因になります。

※WASでコネクションプール（DBCP）を多く設定したらメモリ使用が多くなりますが、多いアクセスに対して処理ができる、逆にコネクションプールを低く設定したらその分、返却の待ち時間が長くなります。

アクセス数を考慮した上で、最適なコネクションオブジェクトを生成しておかなればならないですね。

Hikari CPのドキュメントを見ていただくの以下のように定義してあります。

connections = ((core_count * 2) + effective_spindle_count)

スピンドルというのはHDDの軸のことです。DBサーバがSSDを搭載している場合、スピンドル数は0とみなすことができます。なぜなら、スピンドル数の分コネクション数を増やしているのは、HDDではI/Oの待ち時間を考慮する必要があるからです。

例えば、１ハードディスクで４コア i7 サーバーは、次の接続プールを実行する必要があります。

9 = ((4 * 2) + 1)