はじめての性能試験：用語＆観点の早見表（番外編）

s-kunishima

性能試験シリーズ（第1回・第2回・第3回）で出てきた用語に加えて、本編では触れなかった一般的な用語・観点も広く集めた早見表です。自分の備忘を兼ねて、「そもそも性能試験にはどんな言葉・着眼点があるのか」をざっと見渡せることを狙いました。厳密な定義より、現場で困らない程度のイメージを優先しています。カテゴリ順に眺めても、気になる言葉を拾い読みしてもOKです。

速さ・時間の指標

用語ざっくりの意味
レスポンスタイムリクエストを投げてから応答が返るまでの時間。速さの基本指標。
ターンアラウンドタイム（TAT）処理を依頼してから結果がすべて返るまでの総所要時間。Webではレスポンスタイムとほぼ同義で使われることが多い。
レイテンシ要求してから応答が返り始めるまでの遅延。ネットワークや処理の待ちを指す。
待ち時間（キューイング遅延）処理されるのを行列で待っている時間。混むほど伸びる。
処理時間（サービスタイム）実際に処理にかかった時間そのもの。待ち時間とは分けて考える。

量・スループットの指標

用語ざっくりの意味
スループット単位時間あたりにさばける処理の量。処理能力の「量」を表す。
RPS／QPS／TPS1秒あたりのリクエスト数／クエリ数／トランザクション数。スループットの代表的な単位。
同時接続数／同時ユーザー数同時にアクセスしている量。負荷の大きさを表す。
同時実行数（並列度・Concurrency）同時に処理の途中にあるリクエストの数。
仮想ユーザー（VU）負荷ツール上で模擬する1人のユーザー。VUを増やして負荷を上げる。

分布・統計の見方

用語ざっくりの意味
平均値全部の平均。少数の極端に遅い値に引っ張られ、実態を隠すことがある。単独では使いにくい。
中央値（p50）ちょうど真ん中の値。半分はこれより速く、半分は遅い。分布の中心をとらえる目印で、全体がじわっと遅くなっていないか（劣化の検知）に向く。
パーセンタイル速い順に並べ、下からX%地点の値を見る見方。平均と違い、一部の遅いリクエストに引きずられにくい。
p90／p95／p999割／95％／99％がこの値以内、という点。p90は要件判定に、p99は「いちばん遅い1%の裾」を見るのに使う。
最大値・最小値いちばん遅い・速い値。最大値は異常の有無の目安。
ばらつき（標準偏差）値の散らばり具合。大きいほど不安定で、体験が読みにくい。
外れ値ごく限定的・断続しない形でしか出ない異常値。無視してよいかは根拠とともにPOと合意する。
ヒストグラム値の分布を棒グラフで見たもの。二つの山（二峰性）など、平均やp50だけでは見えない形が分かる。

品質・可用性の指標

用語ざっくりの意味
遵守率基準を満たしたリクエストの割合。「5秒以内・遵守率90%」なら9割が5秒以内でOK。
エラー率全リクエストに占める失敗（5xxなど）の割合。速さとは別の品質シグナル。
可用性／稼働率使える時間の割合（例：99.9%）。性能というより障害・運用寄りの観点。
SLI／SLO／SLA測る指標（SLI）／自分たちの目標（SLO）／顧客との約束（SLA）。合格基準の土台になる考え方。
Apdex満足／許容／不満の閾値から算出する、ユーザー満足度を0〜1で表す指標。
エラーバジェット許容できる失敗の「予算」。SLOを下回らない範囲でどこまで攻めてよいかの目安。

試験の種類（負荷の「かたち」）

用語ざっくりの意味
性能試験／負荷試験システムに負荷をかけ、要件どおりの性能が出るかを確かめる試験の総称（両者は曖昧に使い分けられることも多い）。
ロード（負荷）試験想定されるピーク相当の負荷をかけ、要件を満たすかを見る基本形。
ストレス試験想定を超えて限界まで上げ、どこで壊れ、どう復帰するかを見る。
スパイク試験短時間に負荷を垂直に跳ね上げ、急増（バズ・CMなど）に耐えられるか、オートスケールが追いつくかを見る。
ロングラン（耐久・ソーク）試験長時間流し続け、メモリリークや接続・トークン枯渇など、時間でじわじわ出る問題を見る。
ボリュームテスト大量データを抱えた状態での挙動を見る。
キャパシティテストどこまでさばけるか上限を測り、将来の増加に備える。
スケーラビリティテスト台数やリソースを増やしたとき、ちゃんと性能が伸びるかを見る。
性能回帰テスト変更の前後で性能が劣化していないかを確かめる。
片系（フェイルオーバー）試験障害で片側が落ちても、縮退した状態でサービスと性能を保てるかを見る（障害試験寄りの観点）。

「現実的な負荷」の作り方（負荷モデル）

用語ざっくりの意味
シナリオ一連のユーザー操作（ログイン→閲覧→詳細表示…）をまとめた単位。
ワークロードモデル誰がどの操作をどの割合でするか、という負荷全体の設計図。
重み各シナリオの出現頻度。よくある操作ほど高くして現実の比率に近づける。
ThinkingTime（考える時間）操作と操作の間に挟む待ち時間。人間が画面を見て考える間を再現する。
ペーシングシナリオ1周の繰り返し間隔。実際の利用ペースに合わせる。
読み書き比率読み取りと書き込みの割合。権限種別と人数比から決めると実態に近づく。
ランプアップ／ランプダウン負荷を階段状に上げる／下げること。「どの接続数から崩れるか」が見える。
定常状態（ステディステート）負荷が一定で安定した区間。この区間の値で評価する。
ピーク／ピーク係数最も混む時間帯の負荷／平常の何倍かという倍率。
オープン／クローズドモデル一定レートで次々来る（オープン）か、決まった人数が回し続ける（クローズド）か、という負荷のかけ方の考え方。
リトルの法則平均同時数 ＝ 到着率 × 平均滞在時間。必要な同時接続数などの見積もりに使える。

計画・基準・合意

用語ざっくりの意味
非機能要件機能そのものではなく、速さ・安定性・可用性といった品質の要求。性能試験の出発点。
合格基準何をもって合格とするかの線引き。要件の数字（例：p90 5秒以内）を事前にPOと合意しておく。
ウォームアップ／コールドスタートキャッシュ等を暖めた定常状態／冷えた最悪ケース。合否はウォームアップ後の値で判定する。
データ条件どれだけのデータ量で測るか。本番稼働後もしばらく劣化しない容量（将来を見込んだ量）をPOと合意して決める。

ボトルネックと切り分け

用語ざっくりの意味
ボトルネック全体の足を引っ張る、いちばん詰まっている箇所。
水平スケール／垂直スケール台数を増やす（水平）／1台を強くする（垂直）。コンテナは水平に強く、DBは共有の土台で増やしにくく上限もある。
オートスケール負荷に応じて自動で台数を増減する仕組み。上限設定が低いとレスポンス頭打ちの原因になる。
サイジングどのくらいのスペック・台数を割り当てるか。想定負荷に対して妥当かを確かめる。
キャパシティプランニング将来の負荷増を見越して、必要なリソース量をあらかじめ見積もること。

DB・アプリの詰まりどころ

用語ざっくりの意味
スロークエリ実行の遅いDBクエリ。DB側ボトルネックの典型。
インデックス検索を速くするDBの仕組み。欠けていると大量データで一気に遅くなる。
N+1問題1件取るたびに追加クエリが飛び、クエリ数が爆発するアプリ設計の不備。
コネクションプールDB接続を使い回す仕組み。足りないと接続待ちやエラーになる。
ガベージコレクション（GC）不要メモリの自動回収。長時間試験で周期的な遅延スパイクの原因になることがある。
メモリリーク使ったメモリが解放されず増え続ける不具合。ロングランで顕在化しやすい。
キャッシュ／ヒット率結果を一時保存して再利用する仕組み／そのうち再利用できた割合。高いほど速く軽い。
レート制限（スロットリング）過剰な負荷を意図的に制限する仕組み（WAFなど）。試験では制限に当たっていないか注意。

監視・計測

用語ざっくりの意味
リソース使用率CPU・メモリなどの使用割合。どの層が詰まっているかの手がかり。
プロファイリング処理の内部を計測し、どこで時間を食っているかを細かく突き止める。
APM（アプリ性能監視）アプリ内部の処理やクエリを可視化し、ボトルネックを追う監視の仕組み。
分散トレーシング1リクエストが複数サービスをまたぐとき、どこで時間がかかったかを追跡する。

ツール

用語ざっくりの意味
Locust／JMeter／Gatling／k6代表的な負荷生成ツール。今回使ったのはPythonでシナリオを書けるLocust。
pgbenchPostgreSQL用のベンチマークツール。DB単体の性能を測る（2段階切り分けの2段目で使う想定）。
CloudWatch／Prometheus・Grafanaメトリクスの収集・可視化に使う監視系。CPUやスケーリング状況などを記録・グラフ化する。
分散負荷（マスター／ワーカー）1台では足りない負荷を、複数台から協調してかける構成。

✨ このカテゴリーのAIまとめ記事を見る

新規CTA