質問

現在、8GB RAM を搭載した 4 CPU Windows ボックスを使用しており、同じボックスに MySQL 5.x がインストールされています。アプリケーションには Weblogic アプリケーション サーバーを使用しています。私たちのアプリケーションでは 200 人の同時ユーザーを目標としています (同じモジュール/画面ではないことは明らかです)。それでは、接続プールで構成する最適な接続数 (最小数と最大数) はどれくらいですか (Weblogic AS の接続プーリング メカニズムを使用しています)。

役に立ちましたか?

解決

この質問には非常に簡単な答えがあります:

接続プール内の接続の数は、WebLogicで設定されたexecスレッドの数と等しくなければなりません

原理は非常に単純です。接続の数がスレッドの数より少ない場合、スレッドの一部は接続を待機している可能性があり、接続プールがボトルネックになる可能性があります。そのため、少なくともexecスレッドの数(スレッドプールサイズ)と等しくなければなりません。

他のヒント

本当に200って言ってたのか 同時 ユーザー数、それともログイン ユーザー数 200 人だけですか?ほとんどの場合、ブラウザ ユーザーは 1 秒あたり 1 ページ以上のリクエストを実行できません。したがって、200 人のユーザーは 1 秒あたり 200 のトランザクションに変換されます。これは、ほとんどのアプリケーションにとってかなり高い数値です。

とにかく、例として、1 秒あたり 200 トランザクションを使用してみましょう。各フロントエンド (ブラウザ) の送信が完了するまでに 0.5 秒かかり、0.5 秒のうち 0.25 秒がデータベースで費やされたとします。したがって、WebLogic ヘッド プールには 0.5 * 200、つまり 100 個の接続が必要となり、DB 接続プールには 0.25 * 200 = 50 個の接続が必要になります。

安全を期すために、負荷の急増を考慮して、最大スレッド プール サイズを予想より少なくとも 25% 大きく設定します。最小値は最大値のほんの一部にすることができますが、その代償として、新しい接続を作成する必要があるため、一部のユーザーにとってはさらに時間がかかる可能性があります。この場合、50 ~ 100 の接続は DB としてはそれほど多くないため、おそらくこれが適切な開始数です。

平均トランザクション応答時間と平均 DB クエリ時間を把握するには、パフォーマンス テストを行う必要があることに注意してください。負荷時の時間は、単一のトランザクションで確認される時間とは異なる可能性があるためです。ユーザー。

接続プールのサイズ設定は簡単なことではありません。基本的に必要なもの:

  • 接続の使用状況を調査するためのメトリック
  • 利用可能な接続がない場合のフェイルオーバーメカニズム

FlexyPool は、適切な接続プールサイズの把握を支援することを目的としています。

次の記事を確認できます:

予想されるさまざまなワークフローのプロファイルを確認してください。また、負荷は対象地域の現在の時刻の関数であることが一般的であるため、接続プールは最近の使用状況に基づいてライブ接続の数を動的に調整することも理想的です。

少数から始めて、適度な数の同時ユーザーに到達してから、それを増やしてください。接続プーリングメカニズムは、他のソフトウェアと比べてスケーラビリティにほとんど貢献していないことがわかると思います。

接続プールは、実際のニーズに基づいて拡大および拡張できる必要があります。ロギングステートメントまたはJMX監視を通じて、実行中のシステムで分析を行うために必要な数値を記録します。 「ピーク検出:Y秒以内にXを超える新しいエントリを割り当てる必要がありました」、「接続がX秒を超えてプールから外れた」などのシナリオのアラートを設定することを検討してください。実際の問題が発生する前にパフォーマンスの問題に注意を向けることができます。

これは、個別にテストおよび決定する必要があるものです-親密に知らない限り、あなたの状況に対して正確な答えを出すことはほとんど不可能です。

このためのハードデータを取得することは困難です。また、言及していない多くの要因にも依存します-

  • 200人の同時ユーザーですが、どのくらいのアクティビティがデータベースクエリを生成しますか?ページの読み込みごとに10クエリ?ログイン時に1つのクエリですか?などなど

  • クエリとデータベースのサイズは明らかに。一部のクエリはミリ秒で実行され、一部は数分で実行されます。

mysqlを監視して、「show processlist」を使用して現在アクティブなクエリを監視できます。これにより、ピーク負荷の下でデータベース内で実際に行われているアクティビティの量をより正確に把握できます。

高トランザクション金融システムでの私の経験に基づいて、たとえば 1秒あたり1Kリクエストを処理したい場合、 32 CPUがある場合、< code> 1000/32 データベースへのオープン接続ポーリング。

ここに私の式があります:

  

RPS / CPU_COUNT

ほとんどの場合、データベースエンジンは非常に少ない数でもリクエストを処理できますが、数が少ない場合、接続は待機モードになります。

データベースがそれらのトランザクションを処理できる必要があることに言及することは非常に重要だと思います(ディスク速度、データベース構成、およびサーバーのパワーに基づきます)。

がんばって。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top