MySQL-持続的接続と接続プーリング
MySQLに対してクエリが起動されるたびに新しい接続を確立するオーバーヘッドを回避するために、2つのオプションが利用可能です。
- 新しい接続が要求される永続的な接続。「同一の」接続がすでに開いているかどうかを確認するチェックが行われます。
- 接続プーリング。クライアントが接続のプールを維持するため、接続を使用する必要がある各スレッドはプールからチェックアウトし、完了時にプールに戻します。
したがって、1秒間に数千のリクエストを処理するマルチスレッドサーバーアプリケーションがあり、各スレッドがデータベースに対してクエリを実行する必要がある場合、より良いオプションは何ですか？
私の理解では、永続的接続では、アプリケーション内のすべてのスレッドがデータベースへの同じ永続的接続を使用しようとします。これらはすべて同じ接続を使用しているためです。そのため、複数のアプリケーションスレッドで共有される1つの接続です。その結果、リクエストはすぐにデータベース側でブロックされます。
接続プーリングメカニズムを使用する場合、すべてのアプリケーションスレッドが接続のプールを共有します。したがって、ブロックリクエストの可能性は低くなります。ただし、接続プーリングでは、アプリケーションスレッドはプールから接続を取得するために待機する必要がありますか、それともラウンドロビン方式でプール内の接続にリクエストを送信し、データベースでキューイングを発生させる必要がありますか？
永続的な接続を持つことは、すべてのスレッドが同じ接続を使用することを意味しません。接続を開いたままにすることは「言う」だけです（接続が必要になるたびに接続を開くことと矛盾します）。接続を開くことは高価な操作であるため、一般に、必要以上に接続を開かないようにします。
これが、マルチスレッドアプリケーションが接続プールを頻繁に使用する理由です。プールは、接続のオープンとクローズ、および接続を必要とするすべてのスレッドがプールからの接続要求を処理します。別のスレッドが接続を使用できるように、スレッドができるだけ早く接続をプールに返すように注意することが重要です。
アプリケーションに接続を必要とする実行時間が長いスレッドが数個しかない場合は、各スレッドの接続を開いて、これを開いたままにすることもできます。
説明したとおり、1つの接続のみを使用することは、最大サイズが1の接続プールと同じです。これは遅かれ早かれ、すべてのスレッドが接続を待機する必要があるため、ボトルネックになります。これは、データベース操作をシリアル化する（特定の順序で実行する）オプションかもしれませんが、シリアル化を保証するより良いオプションがあります。
アプリケーションサーバーが接続を待つべきかどうかについての質問については、答えはイエスです。
MySQL接続がブロックされています。接続を介してMySQLサーバーからリクエストを発行すると、接続はサーバーから応答を受信するまでアイドル状態で待機します。
同じ接続で2つのリクエストを送信し、どちらが最初に返されるかを確認する方法はありません。一度に送信できるリクエストは1つだけです。
したがって、一般的に、接続プールの単一スレッドは、1つのクライアント側接続（この場合、アプリケーションサーバーがクライアント）と1つのサーバー側接続（データベース）で構成されます。
アプリケーションは、プールから利用可能な接続スレッドを待機し、必要に応じてプールを拡大し、ビジーでなくなったときにデフォルトのスレッド数に縮小する必要があります。