3

J2EE アプリケーションのストレス テストに LoadRunner を使用しています。

1 つの MySQL DB サーバーと 1 つの JBoss App サーバーがあります。いずれも 16 コア (1.8GHz) / 8GB RAM ボックスです。

接続プール: DB サーバーは で使用max_connections = 100していmy.cnfます。App Server もand でmin-pool-sizeand max-pool-size= 100を使用しmysql-ds.xmlてmysql-ro-ds.xmlいます。

「通常の」シングルコア PC から 100 人の仮想ユーザーの負荷をシミュレートしています。これは 1.8GHz / 1GB RAM ボックスです。

アプリケーションは、100 Mbps のイーサネット LAN にデプロイされ、使用されています。

ストレス テスト スクリプトのセクションでランデブー ポイントを使用して、実際の並列 (同時ではない) 使用をシミュレートしています。

質問：

この負荷を生成する PC の CPU 使用率は 100% に達することはなく、メモリも利用可能であると思います。したがって、この PC にさらに仮想ユーザーを追加してみることができます。しかし、その前に、同時実行/並列処理とハードウェアに関する 1 つまたは 2 つの基本事項を知りたいと思います。

  1. このロード ジェネレーターのようにシングル コアのロード ジェネレーターだけを使用して、実際に 100 ユーザーの並列ロードをシミュレートできますか (各ユーザーは実際に専用の PC から操作を使用しています)。私のおそらく間違った理解は、シングルコア PC 上の 100 個のスレッドが同時に (つまり、インターリーブされて) 実行されるが、並列には実行されないということです。 ) たった 1 台のシングルコア PC から! あれは正しいですか？

  2. ユーザーの並列処理に対するネットワーク帯域幅の制限: 負荷を生成する 100 コアの PC (または、LAN 上に 100 台のシングルコア PC があるとしましょう) を持っていると仮定しても、イーサネットの動作では同時実行と同時実行のみが許可されるわけではありません。負荷を生成する PC をサーバーに接続するイーサネット ワイヤ上のユーザーの並列処理ではありません。実際、マルチコア ボックスのアプリ サーバーに到達するユーザー リクエストはインターリーブされてしか到達できないため、この問題 (ユーザーの並列処理の欠如) は、実際のアプリケーションの使用 (ユーザーごとに 1 台の PC) でも持続するようです。 . つまり、マルチコア サーバーがユーザー要求を並行して処理できるのは、各ユーザーがサーバーとサーバーの間に専用の物理層接続を持っている場合だけです。

  3. (上記の「問題」により) 並列処理が達成できず、同時実行と呼ばれる次善の策のみが可能であると仮定すると、シミュレーションを使用するハードウェアとネットワークの仕様をどのように選択すればよいでしょうか。たとえば、(a) 負荷を生成する PC はどの程度強力であるべきか? (b) これらの PC ごとに作成する仮想ユーザーの数は? (c) LAN 上の各 PC は、スイッチの代わりにハブを使用する場合に発生するブロードキャスト トラフィックを (回避するために) スイッチを介してサーバーに接続する必要がありますか?

前もって感謝します、

/HS

4

4 に答える 4

1

あなたはこれを少し考えすぎているように思えます。サーバーは高速で新しく、多数のクライアントを処理するのに十分適しています。ボトルネック (ある場合) は、アプリケーション自体または 100m ネットワークのいずれかになります。

1./2. クライアントではなくサーバーをテストしています。この場合、クライアントが行っているのはデータの送受信だけです。クライアント処理 (HTML のレンダリング、画像のデコード、JavaScript の実行など) のオーバーヘッドはありません。最近の unicore マシンは、ギガビット リンクを簡単に飽和させる可能性があります。100 メガビットのパイプは簡単なはずです。

また、新しい/高性能のイーサネット カードのプロセッサは、CPU から多くの作業をオフロードするため、必ずしも CPU ヒットを期待する必要はありません。

3. ハブを使用しないでください。craigslist で 5 ドルで 1 億ハブを購入できるのには理由があります。

于 2011-01-27T07:58:10.350 に答える
1

アプリケーションをよく理解していないと、これに答えるのが難しい場合がありますが、一般的に言って、サーバーの「真の」ストレス テストを達成するには、100 コアが理想的です (100 同時実行のターゲットを使用)。ユーザー）、つまり 100 台の PC。ただし、さまざまな問題により、これはおそらく簡単なことであることがわかります。

非同期ソケットを使用する数年前に構築した通信エンジン (.NET / C#) があります。可能な限り高速にする必要があったため、HTTP やその他のより高度な抽象化などのソケットの上にレイヤーを追加することを忘れなければなりませんでした。4 GB の RAM を搭載したクアッド コア 3.0 GHz コンピューターで実行すると、サーバーは最大 2,200 の同時接続のトラフィックを簡単に処理できます。Gb スイッチがあり、すべての PC に Gb NIC があります。すべての PC が同時に通信している場合でも、そのサーバーでプロセッサの負荷が 30% を超えることはめったにありません。これは、「システム全体」に内在するすべての遅延によるものだと思います。

現在実装している 50,000 人の同時ユーザーをサポートするという新しい要件があります。サーバーには、デュアル クアッド コア 2.8 GHz プロセッサ、64 ビット OS、および 12 GB の RAM が搭載されています。私たちのモデリングは、このコンピュータが 50,000 人のユーザーを処理するのに十分すぎることを示しています。

私が言及したネットワーク遅延 (CAT 3 対 CAT 5 対 CAT 6 の問題を忘れないでください)、データベース接続、保存されるデータの種類と平均レコード サイズ、参照の問題、バックプレーンとバスの速度、ハード ドライブの速度などの問題サイズなどは、プラットフォームを「全体的に」遅くする上で何よりも重要な役割を果たします。システムには 500 人、750 人、1,000 人、またはそれ以上のユーザーがいると思います。

これまでの目標は、スレッドを長時間ブロックしたままにしないことでした。新しい目標は、すべてのコアをビジー状態に保つことです。

毎日 ~7,800 の URL のコンテンツをダウンロードして分析する別のアプリケーションがあります。24 GB の RAM を搭載したデュアル クアッド コア 3.0 GHz (Windows Ultimate 7 64 ビット エディション) で実行すると、プロセスが完了するまでに最大 28 分かかりました。ループを Parallel.ForEach() に切り替えるだけで、プロセス全体の所要時間が 5 分未満になりました。私たちが見たプロセッサ負荷は常に 20% 未満であり、最大ネットワーク負荷はわずか 14% です (標準 Gb ダム ハブと T-1 回線を介した Gb NIC 上の CAT 5)。

すべてのコアをビジー状態に保つことは大きな違いをもたらします。IO の待機に多くの時間を費やすアプリケーションでは特にそうです。

于 2011-01-27T16:32:35.010 に答える
1

イーサネットを使用しているだけでなく、信頼できるプロトコルに固有の組み込みのラウンドトリップを備えた信頼性の高い順序付けられたプロトコルである TCP ソケットの上にある HTTP(S) を介して話している Web サービスを作成していると仮定します。ソケットは IP の上にあります。IP パケットがイーサネット フレームと一致しない場合、ネットワークを十分に活用することはできません。UDP を使用していて、イーサネット フレームに合わせてデータグラムを形成し、サーバーに 100 個のロード ジェネレーターと 100 個の 1Gbit イーサネット カードを使用していたとしても、それらはまだ割り込みで動作しており、もう少し下に多重化する時間があります。スタック。

ここでの各レベルはトランザクションの観点から考えることができますが、すべてのレベルを一度に考えるのは意味がありません。OSI モデルのレベル 7 で動作する SOAP アプリケーションを作成している場合、これがドメインになります。あなたに関する限り、トランザクションは SOAP HTTP(S) リクエストであり、それらは並行しており、完了するまでにさまざまな時間がかかります。

さて、あなたの質問に実際に答えてみましょう。テスト スクリプト、使用するメモリの量、さらにはアプリケーションの応答速度によって異なります。200 以上の仮想ユーザーは問題ありませんが、ボトルネックを見つけることは科学的な調査の問題です。実験を行い、それらを見つけ、それらを広げ、満足するまで繰り返します. Load Generator とテスト中のシステムからシステム メトリックを収集し、OS プロバイダーの推奨事項と比較し、瀕死のシステムと動作中のシステムの違いを調べ、プラトーに達するグラフを探します。

于 2011-01-29T03:55:43.840 に答える
0

ユーザーを代表しているので、同時動作を維持するためのエンジニアリング要件がないか、エージェントがプロセスであり、人間のユーザーではなく、これらのエージェントがクロックティックによって管理されている場合を除き、ランデブーは無視してください。人間は混沌としたコンピューティングユニットであり、読み取り、入力、友人との会話などがどれだけ速くできるか、できないかに基づいて、さまざまな到着ウィンドウと出発ウィンドウがあります。人口行動に関する優れた本は、James Gleik（sp？ ）。

100人の分離されたユーザーが、観察可能な条件で瞬時に動作が高度に同期する確率はゼロです。ただし、ビジネスの朝の午前9時から10分以内に100人のユーザーがログインするなど、定義された時間枠内での同時アクティビティの確率は非常に高くなる可能性があります。

ちなみに、ランデブーが強調された履歴書は、ツールの理解が不十分でパフォーマンステストプロセスが不十分な人にとってのナンバーワンのマーカーです。これは、過去15年間に実施された1500を超えるインタビューのフォリオからのものです（私は1996年4月1日にMercuryの従業員として始めました）

ジェームズ・プーリー

モデレータ

-SQAForums WinRunner、LoadRunner

-YahooGroups LoadRunner、Advanced-LoadRunner

-GoogleGroups lr-LoadRunner

-Linkedin LoadRunner（所有者）、LoadrunnerByTheHour（所有者）

マーキュリーミョウバン（1996-2000）

NewcoeパフォーマンスエンジニアリングCTO

于 2011-04-02T22:53:41.357 に答える