mysql の接続プロセスは他の RDBMS に比べて非常に高速になるように設計されているため、接続プールを提供するライブラリ(SQLAlchemy) を使用しても、接続プールを有効にすると実際にはそれほど役に立たないという話を聞いたことがあります。
誰もこれについて経験がありますか？
一部のコードが db 接続に対してステートフルな処理を行っており、(おそらく誤って) それ自体がクリーンアップされない場合、通常は接続を閉じるときにクリーンアップされる状態が代わりに再利用された接続を取得する後続のコードに伝播されます。
アプリケーションがトランザクション分離レベルなどの接続全体のオプションを変更しない限り (通常はそうではありません)、SQLA の接続プールを使用する場合、接続の残留状態について心配する必要はありません。SQLA の接続プールは、チェックイン時に接続に対して connection.rollback() を発行し、トランザクション状態またはロックがクリアされるようにします。
特に同じマシンで UNIX ソケット経由で接続している場合は、MySQL の接続時間がかなり速い可能性があります。接続プールを使用する場合は、MySQL のクライアント ライブラリが 8 時間以上アイドル状態の接続を自動的にシャットダウンするため、一定期間後に接続がリサイクルされるようにする必要もあります (SQLAlchemy では、これは pool_recycle オプションです)。
プールの実装をデフォルトの QueuePool から実際には何もプールしないプールの実装である NullPool に変更することで、SQLA アプリケーションを使用する場合とそうでない場合の接続プールのベンチングをすばやく行うことができます。プロキシ接続が取得され、後で閉じられます。
MySQL 自体の接続部分が非常に洗練されていても、ネットワーク接続が関係していると思われます (それがループバックか物理かに関係なく)。大量のリクエストを行うと、かなりの費用がかかる可能性があります。もちろん、アプリケーションが何をするかに依存します (よくあることですが) もちろん、接続ごとに多くの作業を行っている場合は、それが支配的であり、多くは得られません。
疑わしい場合は、ベンチマーク - しかし、接続プーリング ライブラリ (少なくとも、評判の良いもの) が適切に動作し、適切にリセットされることを概して信頼します。
簡単な答え：あなたはそれをベンチマークする必要があります。
長い答え：それは状況次第です。MySQLは接続セットアップが高速であるため、そのコストを回避することは接続プールを選択する理由にはなりません。あなたが勝つ場所は、クエリの実行が少なくて速い場合です。それは、プーリングで勝つことがわかるからです。
もう1つの懸念は、アプリケーションがSQLスレッドをどのように処理するかです。SQLトランザクションを実行せず、スレッドの状態についての仮定を行わない場合、プーリングは問題になりません。OTOH、一時テーブルを破棄したり、トランザクションをロールバックしたりするためにスレッドを閉じることに依存するコードでは、プーリングに関して多くの問題が発生します。
The connection pool speeds things up in that fact that you do not have create a java.sql.Connection object every time you do a database query. I use the Tomcat connection pool to a mysql database for web applications that do a lot of queries, during high user load there is noticeable speed improvement.
Django を使用して単純な RESTful サービスを作成し、接続プールを使用して、または使用せずにテストしました。私の場合、違いはかなり顕著でした。
LAN では、それがない場合、応答時間は 1 ～ 5 秒でした。それにより、20ミリ秒未満。結果は異なる場合がありますが、MySQL および Apache サーバーに使用している構成はかなり標準的なローエンドです。
インターネット経由で UI ページを提供している場合、余分な時間はユーザーに気付かれないかもしれませんが、私の場合は許容できないので、プールを使用することにしました。これがお役に立てば幸いです。