Webpshere ApplicationServer6.1内でWebアプリケーションを実行しています。このWebアプリケーションには、ルールの種類のエンジンがあり、すべてのルールがWebsphereデータソースプールから独自の接続を取得します。したがって、ユースケースを実行すると、100レコードの入力に対して、約400〜800の接続がプールから取得され、プールに解放されることがわかります。このエンジンが生産に入ると、処理が完了するまでに時間がかかりすぎるのではないかと感じています。
プールから頻繁に接続を取得するのは悪い習慣ですか？プールから接続を取得するために必要なオーバーヘッドコストはどれくらいですか？私の推測では、プールはリソースキャッシュにすぎないため、関連するコストは最小限に抑える必要があります。私が間違っている場合は訂正してください。
別のユーザーが準備完了の接続をデータベースに接続し、データベースが接続を再度開く必要がない場合、接続プールは接続を維持します。
接続を開くことは1回限りのことではないため、これは実際には良い考えです。サーバーへのアクセスは多数あります（認証、取得、ステータスなど）。したがって、Webサイトに接続プールがある場合は、顧客により速くサービスを提供できます。
あなたのウェブサイトが人々によって訪問されない限り、あなたはあなたのために働く接続プールを持たないわけにはいかないでしょう。
プールはあなたの問題ではないようです。本当の問題は、「ルールエンジン」が計算全体を完了する前に、接続をプールに解放しないという事実にあります。エンジンのスケーリングがうまくいかないので、そう思われます。データベース接続の数が処理中のレコードの数に何らかの形で依存している場合、ほとんどの場合、何かが非常に間違っています。
エンジンに接続をできるだけ早く解放させることができた場合、必要な接続は数百ではなく数である可能性があります。それができない場合は、ルールエンジンが接続を要求するたびに同じ接続を再利用する接続ラッパーを使用できますが、接続プールを持つことの利点は多少無効になります...
言うまでもなく、多くのマルチスレッドおよびトランザクション分離の問題が発生します。接続が読み取り専用の場合は、オプションになる可能性があります。
接続プールは、接続の再利用がすべてです。
接続が不要なときに接続を保持している場合は、その接続が別の場所で再利用されるのを防いでいます。また、これを実行するスレッドが多数ある場合は、プールの枯渇を防ぐために、より大きな接続プールで実行する必要があります。接続が増えると、作成と確立に時間がかかり、維持するためにより多くのリソースが必要になります。接続が古くなるにつれて再接続が増え、データベースサーバーも接続数の増加の影響を受けます。
言い換えると、プールを使い果たすことなく、可能な限り最小のプールで実行する必要があります。そして、それを行う方法は、接続をできるだけ保持しないことです。
私はJDBC接続プールを自分で実装しました。多くのプールの実装はおそらくより高速である可能性がありますが、プールで発生しているスラックは、クエリの実行にかかる時間によって矮小化される可能性が高いため、気付かない可能性があります。データベース。
つまり、接続プールは、接続を返すときにそれが大好きです。またはとにかく彼らはすべきです。
プールがボトルネックであるかどうかを実際に確認するには、プログラムのプロファイルを作成する必要があります。プールに問題がある場合は、チューニングに問題があります。単純なプールは、1秒あたり100Kの割り当て以上、または約10マイクロ秒を処理できる必要があります。ただし、接続を使用するとすぐに、何か便利なことを行うのに200〜2,000マイクロ秒かかります。
これは悪いデザインだと思います。Reteルールエンジンが暴走しているように聞こえます。
スレッドごとに最小0.5〜1.0 MB（スタックなど）を想定すると、大量のメモリがスラッシングされます。プールの内外の接続をチェックすることで、問題が最も少なくなります。
知るための最良の方法は、パフォーマンステストを実行し、メモリ、各操作のウォールタイムなどを測定することです。しかし、これはうまく終了するようには思えません。
時々、人々は、それが「標準的」でハイテクであるという理由だけで、すべてのルールをBlaze、ILOG、JRules、またはDroolsに投げ込むと思い込んでいるのを目にします。これは素晴らしい履歴書の項目ですが、これらのソリューションのうち、より単純なテーブル駆動型の意思決定ツリーによってより適切に提供されるものはいくつありますか？多分あなたの問題はそれらの1つです。
いくつかのデータを取得し、問題があるかどうかを確認し、データが必要であると示している場合は再設計する準備をすることをお勧めします。
ルールエンジンが正確に行うことについて詳しく教えてください。各ルールの「起動」がデータ更新を実行している場合は、接続が適切に解放されていることを確認する必要があります（これをコードのfinallyブロックに入れて、接続が実際に解放されていることを確認します）。
可能であれば、データの更新をメモリバッファーにキャプチャし、ルールセッション/呼び出しの最後にのみデータベースに書き込むことを検討することをお勧めします。
データベース操作が読み取り専用の場合は、情報をキャッシュすることを検討してください。
400〜800の接続が作成されてプールに解放されるのは悪いことですが、400〜800のプールされていない接続を作成して閉じる必要がある場合は、さらに悪化すると思います。