現在、同じボックスに MySQL 5.x がインストールされた 8 GB RAM の 4 CPU Windows ボックスを使用しています。アプリケーションにWeblogicアプリケーションサーバーを使用しています。アプリケーションで 200 人の同時ユーザーをターゲットにしています (明らかに、同じモジュール/画面ではありません)。では、接続プールで構成する必要がある最適な接続数 (最小数と最大数) はいくつでしょうか (weblogic AS の接続プーリング メカニズムを使用しています)。
8 に答える
本当に 200 人の同時ユーザー、または 200 人のログイン ユーザーのことですか? ほとんどの場合、ブラウザ ユーザーは 1 秒あたり 1 ページ以上のリクエストを実行できません。したがって、200 ユーザーは 1 秒あたり 200 トランザクションに変換されます。これは、ほとんどのアプリケーションにとってかなり高い数値です。
いずれにせよ、例として、1 秒あたり 200 トランザクションで行きましょう。各フロントエンド (ブラウザ) の tx が完了するまでに 0.5 秒かかり、0.5 秒のうち 0.25 秒がデータベースで費やされるとします。したがって、WebLogic のスレッド プールには 0.5 * 200、つまり 100 の接続が必要であり、DB 接続プールには 0.25 * 200 = 50 の接続が必要です。
安全を期すために、最大スレッド プール サイズを、負荷のスパイクを許容できると予想されるサイズよりも少なくとも 25% 大きく設定します。最小値は最大値のごく一部である可能性がありますが、新しい接続を作成する必要があるため、一部のユーザーでは時間がかかる可能性があるというトレードオフがあります。この場合、50 から 100 の接続は DB にとってそれほど多くないため、おそらく開始数として適切です。
平均トランザクション応答時間と平均 DB クエリ時間を把握するには、パフォーマンス テストを行う必要があることに注意してください。ユーザー。
この質問には非常に簡単な答えがあります。
接続プール内の接続数は、WebLogic でコンフィグレーションされた実行スレッドの数と同じである必要があります。
理由は非常に単純です。接続の数がスレッドの数よりも少ない場合、スレッドの一部が接続を待機している可能性があり、接続プールがボトルネックになります。したがって、少なくとも exec スレッドの数 (スレッド プール サイズ) と同じである必要があります。
予想されるさまざまなワークフローをプロファイリングして確認する必要があります。理想的には、接続プールは最近の使用状況に基づいてライブ接続の数も動的に調整します。これは、負荷がターゲットの地理的領域の現在の時刻の関数であることが非常に一般的であるためです。
少数から始めて、妥当な数の同時ユーザーに到達するようにしてから、それを増やしていきます。接続プールのメカニズムは、他のソフトウェアほどスケーラビリティに役立たないことに気付くでしょう。
接続プールは、実際のニーズに基づいて拡大および縮小できる必要があります。ロギング ステートメントまたは JMX 監視を使用して、実行中のシステムで分析を行うために必要な数値をログに記録します。「ピークが検出されました: X を超える新しいエントリを Y 秒で割り当てる必要がありました」、「接続が X 秒を超えてプール外でした」などのシナリオのアラートを設定することを検討してください。これにより、パフォーマンスの問題が発生する前に注意を払うことができます。本当の問題。
これは、個別にテストおよび決定する必要があるものです。状況に精通していなければ、状況に正確な答えを出すことはほとんど不可能です。
このためのハードデータを取得することは困難です。それはあなたが言及していない多くの要因にも依存しています-
200人の同時ユーザーですが、どのくらいのアクティビティでデータベースクエリが生成されますか?ページの読み込みごとに10クエリ?ログイン時に1つのクエリ?などなど。
明らかにクエリとデータベースのサイズ。一部のクエリはミリ秒単位で実行され、一部は分単位で実行されます。
「showprocesslist」を使用して、mysqlを監視して現在アクティブなクエリを監視できます。これにより、ピーク負荷時にデータベースで実際に実行されているアクティビティの量をより正確に把握できます。