こんにちは。性能テストグループのけんです。この記事では私が主に担当している性能テストについて、引き続き共有していきます。前回の投稿ではテストパターン(ロードプロファイル)の構成要素について説明しました。
今回は、構成要素の中で重要となる負荷量ついて説明していきたいと思います。
<性能テストのススメ 記事一覧> ※クリックで開きます
#1 性能テストの目的と種類
#2 テスト計画
#3 対象シナリオ(運用プロファイル)
#4 テストパターン(ロードプロファイル)第一章_構成要素
#5 テストパターン(ロードプロファイル)第二章_負荷量(入門編)
スレッド数とスループット
性能テストにおいて適切な負荷量を設定するためには、スレッド数とスループットについて理解する必要があります。
ISTQBのシラバスでは、コンカレンシー(スレッド)とスループットについて以下の説明があります。
ワークロードの異なる側面であるスループットとコンカレンシーを理解することは重要である。
運用プロファイルとロードプロファイルを適切にモデル化するには、両方の側面を考慮すべきである。
参考文献:「ISTQB テスト技術者資格制度 Foundation Level Specialist シラバス 性能テスト担当者 Version 2018.J01」
要約すると以下になります。
・スレッドとスループットは別物なのできちんと理解しないといけないよ
・対象シナリオとテストパターンを決定するためには両方を考慮するべきだよ
スレッドとスループットについては前回の投稿で説明しましたが、実際にはイメージしづらい部分もあるかと思いますので、今回は詳しく説明していきたいと思います。
握手会から学ぶスレッド数とスループットの関係
突然ですが、問題です。
【問題】
架空のアイドルグループAGT48※1の握手会があります。
握手会には最大で300人の客が参加します。握手会の制限時間は60分です。
時間内に参加者全員が入退場するためには入場のための受付レーンを何列設置すればよいでしょうか。
【前提条件】
1. 入場から退場までにかかる想定時間は(受付を含め)1人あたり3分
2. 受付レーンから会場に入場できるのは1列あたり1人までで、1人が退場した直後に次の人が入場
※1 AGT48は架空のアイドルグループですが、AGEST(当社)のアイドル「こころちゃん」(画像右上)はデジタルコンシェルジュとして社内で活躍しています。
こころちゃんについては「Cloud FunctionsとSlack APIに踊らされたSlack Bot作成」をご確認ください。
解けましたでしょうか?ここでヒントです。
【ヒント】
(1) 受付レーン1列で60分間あたり何人が入退場できるのか
(2) 60分で300人を捌くためには、(1)を踏まえた上で受付レーンを何列用意すべきか
※注意※ 下の画像の後がすぐ答えになります。もう少しお考えになりたい方はスクロールしないようにしてください。
答えは以下の通りです。
(1)受付レーン1列で60分間あたり入退場できる人数は..
↓
60[分](制限時間)/ 3[分](1人あたりの入退場時間)= 20[人]
(2)受付レーン1列で20人が入退場できるとして、300人を入退場させるためには..
↓
300[人](客総数)/ 20[人](1受付レーン60分あたりの入退場数)= 15[列]
正解は15列でした。
性能テストに置き換えると…
先ほどの例題は性能テストで負荷量を検討する際の基本となります。それでは例題の内容を性能テストに置き換えて解答していきたいと思います。
握手会場を対象システムに置き換え、握手会場に客が入場してから退場するまでにかかる時間を計測対象範囲とした場合、以下の様になります。
問題例 | 性能テストに置き換えると |
---|---|
握手会場 | 対象システム |
握手会場に入場してから退場するまでの動線 | トランザクション |
握手会場に入場してから退場するまでの時間 | トランザクションのレスポンスタイム |
受付レーンの数 | スレッド数 |
時間あたりの入退場者数 | スループット |
これらを置き換えて図にすると以下の通りです。
例題の解き方も置き換えてみます。
(1) 1つの受付レーンで60分間あたり何人が入退場できるのか
↓
1スレッドで60分間あたり何トランザクション実行できるか
↓
60[分](時間範囲)/ 3[分](1トランザクションの処理時間)= 20[トランザクション]
(2) 60分で300人を捌くためには、(1)を踏まえた上で受付レーンを何列用意すべきか
↓
60分で300トランザクションを実行するためには、(1)を踏まえた上で何スレッド用意すべきか
↓
300[トランザクション/60分] / 20[トランザクション/60分] = 15[スレッド]
スレッドを算出するために、目標となるスループット(300[トランザクション/60分])を確認した上で、1スレッドの時間あたりの実行可能な回数(時間範囲/ 1トランザクションの処理時間)を算出してから必要なスレッド数を算出する、という流れになります。
60分あたりのスループットで計算していますが、実際のスループット要件は分間、できれば秒間と、短い単位で算出することが好ましいです。なぜなら、例題では範囲時間が60分と決まっていましたが、範囲時間は今回の様に必ずしも定まっていないことが多いからです。1スレッドで1分あたりのスループットが算出できていれば、範囲時間(負荷継続時間)が変わったとしてもスレッド数の算出が容易となります。
以上を踏まえ、1分あたりのスループットを元に計算してみます。
目標スループット(300[トランザクション/60分])を分間にすると...
↓
300[トランザクション] / 60[分] = 5[トランザクション/分]
1スレッドで1分間あたりのトランザクション実行回数は...
↓
1[分] / 3[分](1トランザクションの処理時間)= 0.3333...[トランザクション/分]
目標トランザクションを達成するために必要なスレッド数は...
1分あたりの目標スループット / 1スレッドで1分あたりのスループット = 必要スレッド数
↓
5[トランザクション/分] / 0.333...[トランザクション/分] = 15[スレッド]
これが汎用的なスレッド数の計算方法となります。
もし上記から条件が変わり、範囲時間(負荷継続時間)が60分→100分に変更となった場合でも、1スレッドあたりの分間スループットが算出済みであれば以下の様に適用できます。
目標スループット(300[トランザクション/100分])を分間にすると...
↓
300[トランザクション] / 100[分] = 3[トランザクション/分]
目標トランザクションに達するために必要なスレッド数は...
↓
3[トランザクション/分] / 0.333...[トランザクション/分] = 9[スレッド]
ポイント
今回は時間あたりの目標となるスループットを元にスレッドを算出するための方法をお伝えしました。※2 この方法では以下の3つが必要となります。
- スループット(時間あたりのトランザクション処理数)の予測値
- 対象シナリオ1回あたりの所要時間予測(上記の例では「対象シナリオ1回 = 1トランザクション」として置き換えていました)
- 対象シナリオに含まれるトランザクション数(上記の例では1トランザクションのみでしたが、実際には複数のトランザクションが存在するのが一般的です)
注意点として、1と2は予測値であるということです。これらはリクエストの応答速度によって変動します。
変動要因としては、負荷をかけた影響によってシステム側のいずれかの処理で遅延が発生することです。
そのため正確な数値は計測するまでわかりません。どこまでの誤差が許容されるかで大きく違いはありますが、1回のテストで想定通りのスループットを出すことは難しいことをご理解いただけると幸いです。
※2 負荷生成ツールによってはスループットを指定して実行する機能もあるので、それを利用することも選択肢の一つです。(考慮する観点が変わるため説明は割愛します)
スレッド数の算出方法は今回紹介した方法以外にも存在します。以下は一例です。
・同時アクセスユーザー数とスループットの両面で算出する場合(ユーザー数=スレッド数とし、シナリオ内でスループットを調整)
・同時アクセスユーザー数のみで定義する場合(ユーザー数=スレッド数とするが、実運用想定となる負荷量との乖離は大きい)
・システムが保持する同時セッション数で定義する場合(時間あたりのセッション数=時間あたりのシナリオ実行回数)
性能テストで適切な負荷量を設定するためには、必要な情報をできる限り収集することが重要です。
さいごに
今回は負荷量について説明しましたが、まだまだ基礎的なお話となっているので引き続き連載していきたいと考えています。
次回記事もどうぞよろしくお願いいたします。
連載一覧
性能テストのススメ #1 性能テストの目的と種類
性能テストのススメ #2 テスト計画
性能テストのススメ #3 対象シナリオ(運用プロファイル)
性能テストのススメ #4 テストパターン(ロードプロファイル)第一章_構成要素
性能テストのススメ #5 テストパターン(ロードプロファイル)第二章 負荷量(入門編)