java - ストレス テスト Tomcat、その動作メカニズムを理解できませんか?

Question

前提:
1. 同社は、http サービスを導入したマシンでストレス テストを実施しました。1 日目は、テストを一晩 (10 時間) 実施しました (同時実行数 200)。時間）、スループットは約 56 % でした。翌日 (この間 Tomcat は再起動されませんでした)、夜間 (10 時間) テスト (一度に 200 の同時実行) も実施されましたが、スループットは約 16% に低下しました。環境は同じなのに、なぜこんなに差が開くのでしょうか？
2. 1 日目に 1,000 同時実行のストレス テストを行ったとき、スレッド数は約 1,000 でしたが、2 日目に 1,000 同時実行のストレス テストを行ったとき (この間 Tomcat を再起動しませんでした)、スレッド数は約 1,000 でした。以前はスレッド数が 700 に減少したのはなぜですか?これはスレッド数に正比例しますが、後は​​そうではありません?

上記の 2 つの前提について、Tomcat には何らかの戦略がありますか、それとも jdbc 接続プールまたは redis 接続プールが上記の現象を引き起こしますか (G1 リサイクル メカニズムを使用)。

Answer 1

この状況は複雑で、プロジェクトの実行環境と依存する他のサービスによって異なります。ストレス テスト環境が複雑な場合 (つまり、多くの人がサーバー上で独自のものを実行している場合)、ストレス テストの結果が不安定になることが予測されます。

スループットの低下が発生した場合は、まずボトルネックがどこにあるのかを特定します。

1. 地元のリソースは逼迫していますか?ネイティブ リソースには主に、CPU、メモリ、ネットワーク帯域幅、ディスク スループットが含まれます。これらには観察と調査が必要です。

2. データベースや外部インターフェースの処理時間が長すぎるかどうかなど、依存するサービスが厳しいかどうか。

3. これらのどれも問題を明確に特定できない場合は、プログラムのデバッグ段階に入ります。各リクエスト処理プロセス中に、各ステップの時間を記録し、ボトルネックとなっているステップを特定します。この粒度は非常に細かく、必要になります。繰り返し変更を記録し、実行し、観察する必要がありますが、問題は必ず見つかります。

問題に遭遇したときにすぐに根拠のないランダムな推測をしないでください。現時点では、問題を追跡し、厳密に分析する必要があります。