1

これは私が思いついた理論的な問題です。

通常、JMeter 負荷テストを実行すると、デフォルトのヒープ設定で十分であることがわかります。

集中的な JMeter 負荷テストを実行しているときに、JMeter が OutOfMemory 例外をスローし、(通常は) より多くのヒープが必要であることを示します。

私はこれら2つの間のケースについて心配しています。JMeter がOutOfMemory をスローしない場合、ガベージ コレクション (JMeter 側) が結果に悪影響を与えていないことを確認する方法はありますか? JMeter を実行するたびに gc ログを監視する必要がありますか?

これのより実用的な側面は次のとおりだと思います。Jmeter が異なるヒープ サイズを使用した 2 つの個別の JMeter テストの出力を比較できますか?

編集: 私が気づいたことの 1 つは、Jmeter UI に、GC オーバーヘッド制限に違反したことを示すアイコンがあることです。しかし、これは JVM から来ており、CPU 時間の 98% が GC に使用されている場所でトリガーされます。この点に到達するずっと前に結果が歪められると思います。

4

1 に答える 1

1

JMeter が OutOfMemory をスローしない場合、ガベージ コレクション (JMeter 側) が結果に悪影響を与えていないことを確認する方法はありますか? JMeter を実行するたびに gc ログを監視する必要がありますか?

ヒープ サイズが結果に影響したかどうかを判断する簡単な方法は、ヒープ サイズを大きくしてテストを再度実行し、違いがあるかどうかを確認することです。これは、テストしているアプリケーションと JMeter JVM に等しく当てはまります。

問題があるという証拠がある場合は、JMeter JVM 設定を変更して、一時停止の少ないコレクターを使用することができます。これにより、明らかな「外れ値」リクエスト時間の数が減る可能性があります...それらが JMeter 側の GC 一時停止によって引き起こされた場合。しかし、(理論的には) JMeter JVM の全体的なスループットも低下する可能性があり、その結果、リクエストを行う平均速度も低下します。

アプリケーションと JMeter が同じハードウェアで実行されている場合は、プロセスの優先順位を調整して、JMeter プロセスが CPU 不足にならないようにすることもできます。

于 2013-04-19T11:07:41.943 に答える