10

以下に関してプールを設定するための最良の方法は何ですか：-

  1. いつ接続を作成しますか？
  2. いつ接続を閉じますか、そしてそれらすべてを閉じますか？
  3. 接続がまだ良好であるかどうかをテストしますか。いつ、どのように？
  4. 接続の最大数の適切な数をどのように把握しますか？
  5. プールのユーザーの行動を確実にするために、どのような監視を行っていますか？1つの悪いコードがすべてを取り出すのを止めることができますか？
  6. 独自のプールを作成しましたか、それともサードパーティのライブラリを使用しましたか？

これは不可知論的な質問だと思いますが、特定のデータベース/言語の「機能」についてのコメントを歓迎します。たとえば、一部のデータベースでは、他のデータベースよりも接続に時間がかかるか、費用がかかる場合があります。

明確にするために、私はプールを最初から作成するつもりはありません。この質問は、プールを実行する既存のライブラリを構成する方法に関するものです。

4

6 に答える 6

6

データベース用の接続プールは、それが単なるデザイン パターンであり、共通のライブラリではなかったときに、Java で作成しました。現在、Tomcat に組み込まれているものを使用しています。

スレッドを使用してプールのいくつかの側面を監視し、いくつかのパラメーターを使用してその動作を制御しました...

  1. minimumInPool="3"... これらの最初の 3 つは、起動時に作成されます。プールが 3 を下回ることは決してありません。
  2. maximumIdleTimeBeforeRemoval="60"... 接続が 1 時間アイドル状態の場合は、接続を破棄して新しい接続を作成します。アイドル時間はおそらく、プールに最低 3 つしかないことを意味します。
  3. maximumInUseTimeBeforeRemoval="30"... 特定の接続が 30 分以上チェックアウトされている場合は、おそらく何か問題があります。それを思い出して、接続を殺します。
  4. maximumTimeBeforeRemoval="60"... 60 分以上経過している場合は削除します。
  5. maximumUsageBeforeRemoval="1000"... 1000 回以上チェックアウトされている場合は削除します。
  6. monitorInterval="15"... 上記のパラメータを 15 分ごとに確認します。

これは数年間非常に役に立ちました。私がこれまでに見たプールの最高値は、ワイルド ピーク時の 151 接続でした。通常、プールは頻繁に使用されている間は約 12 で、早朝の時間帯には最低 3 までアイドリングしていました。

私は Oracle の JDBC シン ドライバーを使用し、Oracle データベースに接続しました。

于 2008-11-07T05:09:34.777 に答える
3

これが私が最近の実装に使用した理論的根拠です。

  1. 接続プールには2種類の接続があります。1つ目は準備ができています。つまり、開いていますが、クライアントは使用していません。2つ目はアクティブで、クライアントが使用していることを意味します。

  2. 接続プールに、最小Nと最大Mの少数の準備完了接続を維持させます。Nは、クライアントが接続を要求するピーク速度に応じて調整できます。準備ができている接続の数がゼロに下がる場合は、より大きなNが必要です。数が一貫して多い場合（たとえば10を超える場合）、より低いNが必要です。

  3. クライアントが接続を希望する場合は、準備ができているものの1つを提供し（アクティブにします）、準備ができているのがN未満の場合は、すぐに新しい接続を開きます（ただし、これが完了するのをクライアントに待たせないでください。プーリングの利点が失われます）。これにより、常に少なくともN個の準備ができた接続が確保されます。クライアントが必要なときに準備ができていない場合は、新しいものを作成する間、クライアントは待機する必要があります。

  4. クライアントがアクティブな接続を終了したときに、準備ができている接続がM未満の場合は、クライアントを準備完了状態に戻します。それ以外の場合は閉じます。これにより、Mを超える準備ができた接続を確立できなくなります。

  5. 接続が古くなるのを防ぐために、準備ができている接続を定期的にリサイクルしてください。準備ができている接続がN個を超える場合は、最も古い接続を閉じてください。それ以外の場合は、閉じてからもう一度開きます。

これには、サーバーに過負荷をかけることなく、接続プールで十分な準備ができて若々しい接続を利用できるという利点があります。

于 2008-11-07T04:34:15.473 に答える
2

私は、車輪の再発明をすべきではないというマットbに同意します。

ただし、Commons DBCPの使用は、これとこの質問の回答に基づいて議論の余地があります。c3poやproxoolのようなそこに言及されているより良い選択肢があります。

または、rdbmsに依存する接続プールメカニズムを使用することもできます。

于 2009-02-09T11:58:29.893 に答える
2

あなたが接続を使用しているコンテキストが何であるかはわかりませんが、私にとってうまくいくと思われるものを共有できます.

バックエンドとして SQL サーバーを使用し、キャッシュと組み合わせてパフォーマンスを向上させています。私の実践では、実際に必要な場合にのみ接続を開いたままにし、接続をプールしないようにして、すぐにクリーンアップし、SQL アクティビティ モニターでアクティブなものとそうでないものを正確に確認できるようにします。各接続はメモリを消費するため、不要なときは鈍い音を立てておくとよいでしょう。

接続のオープンとクローズの質問に答える前に、キャッシングが非常に重要であることを述べさせてください。キャッシュからオブジェクトを取得すると、時間を大幅に節約できます。私のasp.netアプリのいくつかでは、開発でキャッシュがオンになっている場合、遅延をほとんど測定できないことがわかりましたが、DB呼び出しでは、呼び出しを完了するのに15ミリ秒から45ミリ秒かかる場合があり、これは他の遅延を考慮していません要因または負荷。私が使用するもう 1 つの方法は、データの適切なオブジェクト構造であるため、何かが変更された場合にのみ DB を更新します。オブジェクトにいくつかのメソッドを実装しました。IO をできるだけ少なくするようにします。

そうは言っても、ある時点でDBにアクセスして書き込む必要があることは誰もが知っているので、2つの原則に従います。

  1. エネルギーを節約するために、ドアと窓を閉めておきます。ある場所で開いている接続は、別の場所では使用できないことを意味します (または、メモリやその他のリソースがより制限されています)。パフォーマンスが向上したため、プーリングをオフにしました。

  2. 接続が開いているときは、バッチで、または一度にできるだけ多くのことを行います。これはもう少し複雑なので、説明しましょう。

    • 私が使用した 1 つの方法は、すべてのオブジェクトが 1 つの接続オブジェクトを使用できるように、接続オブジェクトをパイプに渡すことです。これにより、アプリによっては 10 以上ではなく、1 つの接続が開いたり閉じたりすることになります。これの良い例は、統計を収集し、複雑な注文パターンをハッシュ化するために SQL サーバーの機能を利用する購入モデルの 1 つです。200K 以上の DB ルックアップを作成している場合や、アプリの目的が何であれ、接続を開いたり閉じたりし続けるのは意味がありません。これの他の部分は、オブジェクトを使用するときに、更新をバンドルして、接続を開いたままにしておく時間を短縮しようとすることです。したがって、insert 呼び出しで scope_identity を実行すると、オブジェクトをキャッシュする前に、挿入と一意の ID のルックアップの両方を処理して、オブジェクトに追加できます。私が最初に ASP アプリを開発していた頃は、ページの読み込みが開始されるとすぐに実際に接続を開き、その後閉じていました。もうそれをすることはお勧めしません。現在、この種の抽象化とレイヤーには大きな利点があり、初心者のプログラマーは注意深く注意することをお勧めします。

私の2セント：

データをキャッシュしましょう！データをキャッシュしましょう！データをキャッシュしましょう！データをキャッシュしてからキャッシュできない場合は、DB アクセスをできるだけ少なくしてください。

于 2008-11-07T05:30:58.523 に答える
2

Jakarta Commons DBCP は、リストしたすべてのことを既に実行しています。

  • 必要に応じて接続を作成し、プールで管理します
  • 一定期間使用されていない場合、接続を閉じることができます
  • 接続を渡す前に接続に対してクエリを実行できます。エラーが発生した場合、接続は破棄され、新しい接続が作成されます。接続は、アイドル時に定期的にテストすることもできます。
  • 作成される接続と、準備する接続の最小数に制限を設定できます。もちろん、制限はアプリケーションに大きく依存します。
  • 方法はわかりませんが、DBCP は接続が閉じられていないことを認識して閉じ、例外をスローして、ログを見たときに何が起こったのかを知ることができます。
  • DBCP には、非常に便利なタイムアウト パラメータがあります。プール内のすべての接続が使用されている場合、接続がプールに返されるまでその期間待機します。制限に達したときに使用可能な接続がない場合は、エラーが発生します。

接続の最小数、作成される接続の最大数、およびタイムアウトをいじって、プールを微調整できます。タイムアウトを長くすると、接続の制限を低くすることができますが、タイムアウトを短くすると、おそらくより多くの数が必要になります。これは、アプリケーションの機能と接続の使用方法に大きく依存します。

于 2008-11-18T19:36:11.523 に答える
1

なぜ車輪を再発明するのですか？

誰かがおそらくすでに問題を解決しており、それよりも優れています。

Java の世界にいる場合は、Commons DBCPを使用できます。

于 2008-11-07T04:04:50.460 に答える