urlscan.io logo urlscan.io
SecurityTrails logo

pr.hedgehog-loader.io Open in urlscan Pro
2a05:d014:58f:6201::64  Public Scan

Back to summary
URL: https://pr.hedgehog-loader.io/blog/41y5h0guyg31kdn8tmyzs3/
Submission: On September 22 via api from US — Scanned from DE

Form analysis 1 forms found in the DOM

<form><input type="file" id="chatlio-file-picker" style="display: none;"><label for="chatlio-file-picker" class="chatlio-file-picker-trigger"><svg xmlns="http://www.w3.org/2000/svg" width="48" height="48" viewBox="0 0 48 48">
      <path fill="#677583"
        d="M28.284 24.756l-7.073 7.073a2.001 2.001 0 0 1-2.826-.002 2.001 2.001 0 0 1-.002-2.826l9.901-9.902a2 2 0 0 0-2.828-2.828l-9.902 9.901a6.001 6.001 0 0 0 .002 8.483 6.001 6.001 0 0 0 8.483.003l7.074-7.074 9.19-9.19c3.515-3.514 3.513-9.22.002-12.73-3.514-3.514-9.214-3.513-12.73.001l-9.19 9.191-9.9 9.9c-4.686 4.686-4.687 12.284 0 16.97 4.687 4.687 12.284 4.688 16.97 0L38.185 29a2 2 0 1 0-2.829-2.829L22.627 38.898a7.999 7.999 0 0 1-11.313 0 8 8 0 0 1 0-11.314l9.9-9.9 9.19-9.19a5.002 5.002 0 0 1 7.073-.002 5.006 5.006 0 0 1-.002 7.073l-9.19 9.19z">
      </path>
    </svg></label></form>

Text Content

TOP 導入事例 機能一覧 ブログ お問い合わせ
 * 
 * 導入事例
 * 機能一覧
 * ブログ
 * お問い合わせ

2021/07/21


負荷テストの指標名と数値の見積もり方を徹底解説

負荷テストを行うにあたって必ず決める必要がのある数値が「同時リクエスト数」です。
「同時アクセス数」「多重度」「秒間リクエスト数」「最大同時接続数」など、様々な紛らわしい用語が使われており、用語とHTTP通信の基本的な仕組みを理解していないと正しい負荷テストを行うことも結果を正しく判定することもできません。
今回は、「同時リクエスト数」とは何か、またどのように決めるべきかについて説明します。


負荷テストを正しく行うために理解したい「HTTP通信の仕組み」

ブラウザの開発者モードを使うとWebページを表示する時の通信はすべて確認、解析することができます。

以下はHedgehogの公式サイトを表示する場合にChromeの開発者ツールで表示したサーバーとの通信ログです。
ページを構成するファイルが順番にリクエストされ、それぞれのレスポンスタイムが確認できます。





HTTP通信の基本的な仕組みは以下の図のようになり、左から右の時間の流れとリクエスト、レスポンスを表しています。





実際はHTTPpipelining、Keep-Alive等、複数のファイルを連続伝送する技術が使われていますが、シンプルに説明すると上記のような動作となります。

クライアントはサーバーに対して「このHTMLをください」「このCSSをください」とファイルの取得要求を出します。（リクエスト）それに対してサーバーはファイルのデータとその他の付属情報をセットにしてクライアントに返します。（レスポンス）
すべてのファイルが取得できたらそれをブラウザ上に描画するのがWebブラウザの役割です。


負荷テスト「同時接続数」の注意点

話を負荷テストに戻します。
注意したい点は「同時接続数」という用語が出てきた場合です。

上記のようにWebページを取得する際には必要なページを構成するファイルを取得してレスポンスを受け取るまでの短い通信が多数行われています。
しかし、受け取ったページをユーザーがブラウザで閲覧している間、通信は発生しません。

このあと説明しますが、仮に1,000ユーザーが同時に利用するWebシステムがあったとしても、全員が1分間に1分しか画面遷移を行わないような場合、同時リクエスト数は平均で16〜17回程度となります。（1,000アクセス
/ 60秒）
サイトの利用者が1,000人いるので同時リクエストも1,000回とはならないということです。
「利用ユーザー数」「同時リクエスト数」は負荷テストの用語として正しいですが、「同時接続数」は基準があいまいになりやすいと思います。

※「同時接続数」はアプリケーションとデータベース間のコネクションのように一定の時間接続を維持することが保証されている場合に使うことが多い用語です。
※わかりやすくするために1回のページ取得 = 1リクエスト と仮定しています。


負荷テストで使う指標名と数値の見積もり方


指標名 見積もり方、説明 A. 利用ユーザー数（人）
負荷試験を行う時間帯にサイトを利用する利用者の「のべ数」です。サイトPVなどの統計情報から導くこともできますし、ログインが必要（利用者の識別が可能）なシステムの場合は、データベースの登録ユーザー数を基準として、特定の時間の利用者合計数を想定することもできます。
B. アクセス回数（回）
利用者がサイトに滞在中に、どのくらいアクセスするか、という数値です。サイトにアクセスしてから離脱するまでの画面遷移の数ということになりますが、利用者が意識しないところでajaxによるバックエンドのサーバー通信が行われるような構成のサイトの場合はそれも見積もりに含める必要があります。
C. アクセス間隔（秒） B.
の頻度です。ページ構成や機能によってアクセス間隔は変わります。（例えば確認ページを挟むような場合はアクセス間隔が短くなります）LPのようなものであれば短いですし、テキスト量が多いサイトや何らかの入力処理を行うビジネス用途のシステムでは長くなる傾向にあります。こちらはサイトの統計情報から導く方法、実際の利用者の動線を想定して、画面遷移のモデルパターンを作成することで見積もることができます。
D. サイト滞在時間（秒） 利用者がサイトにアクセスしてから離脱するまでの平均時間です。B x C で算出することができます。 E. 同時リクエスト数（回） A
x B / C で求めることができます。瞬間のタイミングにHTTPリクエストがどのくらいの数、要求されるか、という数値です。負荷試験で使用する重要な指標です。
F. 安全率・ピーク倍率（倍）
すべてのリクエストが平均的に行われるわけではありません。一時的にアクセスが偏ることを想定して倍率を設定します。2.5〜4倍程度が一般的な値ですが、サイトの性質によって変わりますので、一概には言えない数値です。


上記の表が負荷テストで利用する代表的な指標です。
以下、簡単に見積もりしてみます。（解説ですのでシンプルな要素のみとしていますが実際にはもう少し複雑です）



とあるECサイトのステータス

・繁忙期のピーク時に1時間で3,000注文が入る
・3,000注文のうち、複数商品を購入するユーザーもいるので、注文データを解析したところ、1,500人のユーザーが購入していた。
・対象サイトは[ログイン] > [商品一覧] >[ 商品詳細] > [カートに入れる] > [決済]
までの5ステップで、購入者の平均サイト滞在時間は5分だった。



ECサイトのステータスから導く各指標の見積もり事例

上記より、購入処理の負荷試験を行う場合以下の指標が算出できます。
・A. 利用ユーザー数：1,500人
・B. アクセス回数：5回
・C. アクセス間隔：60秒（5ステップの平均値）
・D. サイト滞在時間：300秒（5分）
・E. 同時リクエスト数：1,500人 x 5回 / 60分 / 60秒 = 2.08回
・F. 安全率：リクエストが偏ることを想定して2.5とする


導き出した同時リクエスト数、2.08回に安全率をかけて同時リクエスト数6回以上の試験テストを行えば良い、ということになります。
6回 x 60秒 x 60分で1時間に21,600回のリクエストを行うペースです。
想定では1,500人 x 5 で 1時間に7,500回のリクエストですので、安全率分もっと多くのリクエストが試験で実行されます。


※実際は、「アカウントがないけどトップページへアクセスしたユーザー」もいるでしょうし、「購入までに複数の商品を比較するはずだからもっとアクセス回数が増える想定」など様々な要素を加味します。
見積もりの甘い、精度の低いテストを行っても信頼性の薄い結果となりますし、逆に高い指標を設定しすぎても、思うように性能が出ずに大変な思いをすることになります。見積もりの精度と明確さが重要です。
負荷テストの実施前に様々な要因をリストアップし、指標を決める必要があります。


まとめ

負荷テストを行う際の同時リクエスト数の見積もり方について説明しました。
現実問題として、リリース前のシステムやアクセスに関する情報がないようなサイト、システムの負荷テストを行わなければならないケースもあると思います。しかしその場合でも正しい指標で仮説を立てて見積もり、負荷テストを行っておけば想定以上のアクセスによる障害時などに仮説が間違っていたかどうかの検証を行うことができます。

Hedgehogでは試験テスト計画の作成支援や上記見積りに関するコンサルティングも行っています。何よりもサイトの障害対策として重要なことは「負荷テストを実施する」ことです。
いくら正しい見積もりを行って仮説を立てても大量アクセスが実際に発生した場合には想定外のエラーや障害が発生します。負荷テストを実際に行い、大量アクセスが発生した時にどのような状態になるのか、どのように復旧すればよいのか、ボトルネックとなるのはどこかを事前に確認しておくことで余裕を持ったシステム運用ができるようになります。
今はAmazonWebService、Microsoft AzureやGoogle App
Engineなど、リソースを比較的柔軟に割り当てることのできるクラウドプラットフォームを利用する場合も多いと思いますが、必要十分なリソース（=運用コスト）にするためにもシステムの限界値を見極めておくことをおすすめします。

Hedgehogに関するお問い合わせはこちら
一覧へ
運営会社 プライバシーポリシー 利用規約
© Astrea Inc.
負荷テストについて質問できます！●


EmailMuteEnd Chat

undefined
Hedgehogサポート
Hedgehogサポート

負荷テストの進め方、お見積り、対応事例など不明点や相談事がありましたらこちらからお気軽にご質問ください。サポート担当者より返信致します。

Powered by Chatlio