負荷テストの作成および実行は、簡単にできる作業ではありません。テストの知識と対象アプリについての深い理解が必要です。

理想的なテストのシナリオは、スクリプトを作成して検証し、BlazeMeter にアップロードして実行した後、わかりやすいレポートをすばやく生成して分析する、というものです。ただし、この手順には多くの可変要素があり、プロセスは簡単なように見えますが、根気が必要であり、また通常は問題解決のために、ある程度のデバッグを行うことが必要になります。

BlazeMeter テストの作成からデバッグ、そして最後に必要な結果を得るための主な手順を示します。

• テストの作成
• BlazeMeter でのサンドボックス テストの実行
• BlazeMeter テストのキャリブレーション
• 結果に従ったテストのデバッグ
• テスト セッション全体の実行

テストの作成

この記事を参照してください。 

BlazeMeter でのサンドボックス テストの実行

サンドボックス設定では、BlazeMeter のクラウドでスクリプトをテストし、すべて正常に動作することを確認できます。

以下のような一般的な問題が発生する可能性があります。

1. ファイアウォール - 使用する環境が BlazeMeter CIDR リストに対して開かれていることを確認し、ホワイトリストに追加してください。
2. すべてのテスト ファイル（CSV、JAR、User.properties など）が存在することを確認します。
3. ファイルへのパス（c:\files\file.csv など）を使用していなかったことを確認します。

サンドボックス テストの詳細については、こちらの記事を参照してください

BlazeMeter テストのキャリブレーション

スクリプトが BlazeMeter で問題なく実行できることを確認しました。次に、1 つの負荷ジェネレータを使用してロードできるユーザの数を調べる必要があります。

テストの設定値を以下のように指定します。

• スレッド数： 500
• Ramp-up： 2400 秒
• Iteration： 無限
• Duration： 50 分
• 1 つの負荷ジェネレータ（エンジン）を使用します。

テストを実行し、モニタリング レポートを通してテストのエンジンをモニタします。

エンジンが、CPU 使用率 75% にもメモリ使用率 85% にも達しなかった場合は（1 回のピークは無視できます）、以下のようにします。

• スレッド数を 700 に変更し、テストを再度実行
• スレッド数 1,000 または CPU 使用率 60% になるまでスレッド数を増やします。

If your engine passed the 75% CPU utilization or 85% Memory usage (one-time peaks can be ignored):

• テストが 75% に達した最初の時点がいつだったかを調べ、その時点のユーザ数を確認します。
• テストを再度実行します。今回はランプアップを 500 に設定するのではなく、前のテストで得たユーザ数を入力します。
• 実際のテストに使用するランプアップ時間を設定し（300 ～ 900 秒から始めるとよいでしょう）、期間を 50 分に設定します。
• テストの最初から最後まで、CPU 使用率 75% またはメモリ使用率 85% を上回らないようにします。

You can also go the safer route and decrease 10% of the threads per load generator.

Looking for a more detailed guide for test calibration? click here.

結果に従ったテストのデバッグ

レポートは、テスト セッションの 1 秒目からリアルタイムで生成されます。
テスト実行のデバッグに必要なほぼすべての情報がレポートで見つかります。

• エラー レポート - テスト中に返されたすべてのエラーを一覧表示します。どのような問題が発生したかを把握できます。たとえば、「403 Forbidden」エラーが多数発生している場合は、負荷ジェネレータで生成されたトラフィックがファイアウォールによってブロックされている可能性があるので、こちらの一覧に従って IP 範囲をホワイトリストに追加する必要があります。
• モニタリング レポート - テスト中、負荷ジェネレータをモニタしながら受信したパフォーマンス インジケータを表示します。CPU またはメモリの値が高い場合は、シナリオが負荷ジェネレータの能力を超えていることを示しています。調整が必要です。
• ログ - ほとんどの場合、コンソールのログと負荷ジェネレータ（エンジン）のログを指します。ログに出力されたエラーを確認できます（たとえば、CSV ファイルが見つからない、Java エラー、beanshell エラーなど）。ログには負荷ジェネレータの状態に関する詳細が記録されるため、モニタリング レポートに示された疑わしい問題を検証できます。
• 集計レポート - ラベルに従って統計を表示できます。エラーが多数生成されているラベルや、他のラベルよりも応答時間が短いラベルがあることがわかります。
• データ レベルにドリルダウンします。

1. レポートの JTL ファイルにドリルダウンします。JTL は、セッションのすべての結果を含むファイルです。JTL を確認する最も簡便な方法は、JMeter の［View Results Tree］リスナで開くことです。
2. 場合によっては、JTL に含まれていない実際の応答のデータを知りたい場合があります。その場合のベスト プラクティスは、スクリプトに Simple Data Writer と呼ばれる JMeter リスナを組み込むことです。これにより、応答データ、応答ヘッダ、アイドル時間などの詳細を追加のログ ファイルに書き込むことができます。

テスト セッション全体の実行

テストをデバッグしてすべてのエラーとストレス ポイントを解決した後、最大負荷で期間全体の実行に移ることができます。
この時点で、自信を持って負荷テストを実行できるようにシナリオを十分に最適化できている必要があります。大規模なテストや長期間のソーク テストも同様に実行します。

詳細については、録画したオンデマンド Web キャスト「How to Make JMeter Highly Scalable and More Collaborative With BlazeMeter （BlazeMeter で JMeter の拡張性と共同作業の効率を高める方法）」をご覧ください。