JMeterの実行方法とスループット・エラー率の読み方
前回までに用意したシナリオを、いよいよ動かします。実行前に確かめること、スレッド数と待ち時間の決め方、GUIではなくCLIモードで動かす理由、結果の読み方までを説明します。
承認された時間帯だけ実行する
前の2つの記事で用意したテスト計画を、いよいよ動かします。動かす前に、承認された開始・終了日時と対象サンドボックスのOrg IDを、申請したときの内容と照らし合わせてください。公式のFAQは「Even approved testing can be throttled if it degrades performance on the instance.」（事前承認があっても、インスタンスの性能を落とすようであれば、承認済みのテストでもスロットリングされることがあります）とも書いています。承認された時間帯・対象サンドボックス以外では動かさないでください。
待ち時間を入れる
人がSalesforceの画面を見てから次の操作をするまでの間は、Uniform Random Timerで表します。公式のコンポーネントリファレンスは、この項目を次のように説明しています。
| 項目 | 意味 |
|---|---|
| Random Delay Maximum | 待ち時間にランダムで加える最大のミリ秒数 |
| Constant Delay Offset | 待ち時間に必ず加える固定のミリ秒数 |
実際の待ち時間は「ランダムな値（0〜Random Delay Maximum）＋Constant Delay Offset」の合計です。Random Delay Maximumに1000、Constant Delay Offsetに2000を入れると、待ち時間は2000〜3000ミリ秒の間でランダムに変わります。
タイマを追加する
スレッドグループの下にUniform Random Timerを追加します。
2つの値を入れる
Random Delay MaximumとConstant Delay Offsetに、それぞれミリ秒で値を入れます。
スレッド数を決める
スレッドグループの設定は3つです。
| 項目 | 意味 |
|---|---|
| スレッド数 | 同時にアクセスする利用者数 |
| Ramp-Up期間 | 全スレッドが動き出すまでにかける秒数 |
| ループ回数 | 1スレッドがシナリオを繰り返す回数 |
公式のユーザーズガイドは、Ramp-Up期間の決め方を「スレッド数と同じ秒数から始めて、様子を見ながら増減する」としています。スレッド数10・Ramp-Up期間10秒なら、1秒に1スレッドずつ動き出す計算です。⚠️ Ramp-Up期間を0に近づけるほど、開始直後に負荷が集中します。申請したRPS（1秒あたりのリクエスト数）を超えないよう、スレッド数とRamp-Up期間を合わせて決めてください。
GUIではなくコマンドラインで動かす
⛔ 実際に負荷をかける実行は、GUIで行いません。公式のガイドは「Don't run load test using GUI mode!」と明記しています。GUIは前の記事で作ったテスト計画の確認・デバッグ用です。
jmeter -n -t plan.jmx -l plan.jtl -e -o report
保存したテスト計画(plan.jmx)をCLIモードで実行し、結果をplan.jtlに書き出し、実行後にHTMLレポートをreportフォルダへ生成します。
| オプション | 意味 |
|---|---|
-n | CLIモード（GUIを使わない）で実行する |
-t | 実行するテスト計画（.jmx）を指定する |
-l | 結果を書き出すファイル（.jtl）を指定する |
-e | 実行後にHTMLレポートを生成する |
-o | HTMLレポートの出力フォルダを指定する。既存の空でないフォルダは指定できません |
結果を読む
テスト計画をGUIで確認する段階では、リスナーで数字を見ます。個々のリクエストを見るならView Results Tree、まとめた数字を見るならAggregate ReportかSummary Reportです。公式のリファレンスは、この2つのレポートが次の列を持つと説明しています。
| 列 | 意味 |
|---|---|
| # Samples | 同じ名前のリクエストが実行された回数 |
| Average | 平均の応答時間（ミリ秒） |
| Min・Max | 最短・最長の応答時間 |
| Error % | エラーになったリクエストの割合 |
| Throughput | 1秒（または分・時）あたりに処理できたリクエスト数 |
Aggregate Reportは個々のサンプルを保持するためメモリを多く使い、Summary Reportは同じ集計をより少ないメモリで行います。スレッド数が多い試験では、Summary Reportを使ってください。
ここで間違えやすい
| 間違い | 何が起きるか |
|---|---|
| 承認された時間帯・対象を確かめずに実行する | 承認済みでも性能低下があればスロットリングされます |
| GUIのまま負荷をかける | 公式が非推奨としている使い方です |
| Ramp-Up期間を極端に短くする | 開始直後にRPSが跳ね上がり、承認した数字を超えます |
| 名前の違うリクエストを同じラベルで記録する | Aggregate Report・Summary Reportの集計が正しく分かれません |
確認した環境
- 2026年9月／CLIモードの起動オプション、Uniform Random Timer・Aggregate Report・Summary Reportの項目の意味を
jmeter.apache.orgのGetting StartedとComponent Referenceで確認しています - 事前承認済みでもスロットリングされ得ることは
help.salesforce.comの公式FAQで確認しています - 負荷試験は、承認済みのサンドボックスでだけ実行してください
まとめ
- 実行の前に、承認された開始・終了日時とOrg IDを申請内容と照らし合わせます。承認済みでも性能低下があればスロットリングされます
- Uniform Random Timerの待ち時間は「ランダムな値＋固定値」の合計です
- Ramp-Up期間はスレッド数と同じ秒数から始めて調整します
- 実際の負荷は
jmeter -n -t ... -l ... -e -o ...のCLIモードで動かします。GUIは確認用です - 結果はAggregate ReportかSummary Reportで、Error %とThroughputを中心に読みます
Salesforceの導入・運用についてご相談ください
導入前の検討から、お使いの環境の改修・運用、AIとの連携まで承ります。状況を伺ったうえで、進め方をご提案します。