アプリケーションで休止状態 3.2.2 を使用しています。接続プーリングには、c3p0 0.9.1 を使用しています。Generic DAO Pattern と Open Session in View パターンを使用してデータベース操作を行っています。
既存のウェブサイトの新しいウェブサイトに取り組んでいます。現在、訪問数は既存のアプリケーションで 50 万ページに達しています。c3p0 構成と混同しています。どのベンチマークで、開く接続の数を決定します。最大接続、最小接続、アイドル時間、タイムアウトなど....
2 に答える
最初に、リクエストが来て、それを処理するための空き接続がない場合にプールが何をするかを決定する必要があります。例外をスローしますか?null を返しますか? 別の接続がプールに返されるまでブロックしますか?
容量を超えたときに何が起こるかがわかったら、呼び出し元のコードでこれをどのように処理できるか、またどのような状況でこれが許容されるかを考えてください。接続数が増加するにつれて、ある時点で、いくつかの要求を処理することを拒否し始める必要がありますが、そのポイントが何であるかを決定できるのはあなただけです。実際のポイントは、次のようなものを含む多くの要因に依存します。
- 現在のアイドルおよびビジー リクエスト率
- これらのレートのボラティリティ (レートが大幅に変動する場合は、より多くの「息抜き」が必要です)
- ハードウェアの改善と開発者がこのコードを修正するために割り当てられた時間と比較した容量の増加に関する将来の予測 (数か月でアップグレードを計画している場合は、数年間実行し続けることを意図している場合よりもオーバーヘッドが少なくて済みます) )
- 処理能力に関する会社の保証
- クライアントが「後で再試行する」要求を理解する能力 - たとえば、503 で 1 分間スリープして再試行する相手側の自動化されたスクリプトであることがわかっている場合、人間が「一時的に容量を超えました」というメッセージを受け取るよりも優れています。どちらも、200 以外の応答を取得してエラーで終了するバッチ スクリプトよりもはるかに優れています。
- リクエストの緊急性 - 一部のリクエスト (子猫の写真を見る) は合理的に遅れる可能性がありますが、他のリクエスト (株式取引注文) は非常に時間に敏感な場合があります。
などなど。
うまくいけば、上記から、同時に処理できるようにする必要があるリクエストの数を考え出すことができるはずです (また、異なるタイプのリクエストがある場合は、これも考慮する必要があるかもしれません)。次に、接続の目標速度を維持するために必要なプール内の接続数を発見するまで、着信要求がどのように接続を取得して使用するかを調べ、推論し、プロファイリングするだけです。
非要求スレッド (ワーカー プールなど) が同じプールから独自の接続を取得する (プールを大きくする必要がある) ことや、実行の一部の接続のみを保持する要求 (プールが小さくなります)。
テスト インスタンスのプロファイルを作成し、構成に小さな変更を加えてから、最後に負荷テストで検証します。