3

JMeter には次のテスト計画があります。

スクリーンショットでは、最初の ThreadGroup の設定を確認できます。これは、テスト計画で一般的な要求量の 50% を占めています (各スレッド グループには、10 個の異なるサブ要求が配置されています)。したがって、これらの設定を使用すると、平均して 1 秒あたり +1 リクエストが追加されます。

ここに画像の説明を入力

次に、このテストを実行して、この図を見ました (エラー %列): ここに画像の説明を入力

エラーをファイルに保存すると、これらのエラーはすべて同じテキストになります。

<sample t="30129" lt="0" ts="1356710138314" s="false" lb="WebService(SOAP) Request 1" rc="000" rm="**Connection reset**" tn="jp@gc - Stepping Thread Group1 3-247" dt="text" by="0"/> 

サーバーの CPU スクリーンショット: ここに画像の説明を入力

データベースの場合: ここに画像の説明を入力

エラーが表示された後、私のコンプはゆっくりとゆっくりと動作を開始しました(ただし、エラーはさらに表示されなくなりました)...そして同時に、サーバーのCPUは徐々に0に低下しました。

教えてください

このエラーの理由は何ですか?

サーバーのタイムアウトに達しましたか? (Max はテーブルで 30 秒を超えているため)。


アップデート。次の設定でテストを再実行しました: 02:46:40 あたり 1000 ユーザー (10 秒あたり +1 スレッド グループ、ループ内の新しいスレッドごとに 10 リクエスト)。つまり、テストの時間とスレッド グループの合計を 2 分の 1 に短縮しましたが、スレッドの追加の強度は節約できました。

結果は同じです (サーバーの CPU 使用率を含む)。990 スレッドが開始された後、«接続のリセット» エラーを受け取りました。スクリーンショットがあります: ここに画像の説明を入力 ここに画像の説明を入力 ここに画像の説明を入力

何か案が?

4

1 に答える 1

1

まず、WebService(SOAP)リクエストは、JMeterでWebサービスをテストするための最良の方法ではありません。今後の2.9バージョンでは非推奨になります。HTTPサンプラーは、パフォーマンスがはるかに優れているため、選択するものです。

次に、接続のリセットは、サーバーが接続を切断したことを意味します。高いように見えるCPUから来ている可能性がありますが、確かではありません。

「マイコンプ」と呼ばれるものが、JMeterをホストしているコンピューターの動作が遅い場合、JMeterインスタンスは、構成したスレッドの数(2003以上?)に圧倒されます。それは多くの要因から来る可能性があります、これを読んでください:

于 2012-12-28T20:08:59.420 に答える