7. 負荷テストの評価基準には何を使えばよいのか?

~テストツールを使う際の負荷量の指標~

6. システムがパフォーマンスを維持するためのメモリ管理について  に戻る

はじめに

性能テスト、負荷テストを行う上では、達成すべき目標値の定義が必要となります。しかし、性能テストでは様々な指標が存在しており、どの指標をもって目標とし、結果を判定すべきか判断が難しい場合があるでしょう。

実際に、Webシステムの性能評価を行うための指標には以下があります:

* 同時接続ユーザー数(Number of Virtual Users)

* 時間あたりのユーザーシナリオ実行本数(Transactions per hour)

* 時間あたりのページ処理数(Received pages per hour)

* 時間あたりのヒット数(Hits per hour)

* サーバー平均応答時間(Average Server times, etc.)

* サーバー側のCPU使用率

また、お客様やマーケット部門等がシステム部に求める指標は、実際に何人の顧客が使って大丈夫なシステムなのかどうかという顧客サイドの観点が含まれてくるでしょう。

今回は、これら様々な指標の中から、一体何を基準にしたら良いのか、また、どのようにその目標値を設定すれば良いのかを解説致します。

訪問者数を目標値にすることの難しさ

Webページのアクセス数の統計を算出する場合に、アクセスログやアナライザー等でヒット件数やページ数だけではなく、訪問者数のカウントまで統計が取れているケースがあります。つまり、1時間あたりに推定で何人のお客様がそのサイトを訪れたかという件数の指標を得ているわけです。

これは、お客様やマーケット部門から見ると 非常に判り易い指標であり、出来ればテスト目標としてはこの数値で示して欲しいと望まれることも多いでしょう。

しかし、実際には、訪問者それぞれの振る舞いで、サーバーに掛かる負荷量は全く異なるため、訪問者数は客観的な性能限界の指標になりにくいという問題があります。

例えば、コマース系のサイトで、トップページやサーチエンジン等から参照して特定の商品のみ1ページだけを閲覧して去って行くユーザーが50人いたケースと、サイト内の各商品を巡回閲覧して望みの商品を比較検討した上で購入までおこなったユーザーが1人いた場合に、この50人のケースと1人のケースでサーバーに渡したリクエスト処理がほぼ同等になる場合があります。

このように50倍の誤差が出るようでは、客観的な指標としての訪問者数の概念は十分ではありません。

もっとも、標準のユーザー操作パターンがアクセス統計的にも裏付けられている場合には、テスト結果のヒット数やページ処理数から、想定訪問者数を算出することは可能です。また、複数のテストシナリオの平均ページ数が、アクセス統計の訪問者数あたりのページ数と一致している場合には、処理されたトランザクション数をそのまま、訪問者数に相当するものとみなしても良いでしょう。

システムの性能を測定するにはヒット数かページ数

基本的にはシステムの処理能力を判定する基準は、秒間あたりのヒット数や、ページ数として、最大でどのくらいまで処理をサーバーが返せるかという指標になります。

テスト対象となるWebコンテンツで、画像ファイルや動的オブジェクトを多数含んでいるページとそうで無いページのばらつきが大きい場合には、ページ間の差異の影響を受けないようによりプリミティブなヒット数をもって指標とします。

逆に、ページ間のコンテンツのばらつきが少なく、また、特に、サーバー側の動的処理の負荷に着目したい場合には、画像ファイルやその他静的コンテンツは出来るだけ排除した形で、ページ数を指標にして計測することも出来ます。

また、ヒット数は、同じ形態のシステムでは、負荷量との関係がほぼ一定の場合も多いため、客観的な指標としても有効です。

訪問者数の読み替えは、アクセス統計の訪問者一人あたりの閲覧数やヒット数平均を参照し、計測されたヒット数やページ数を、この一人あたりの平均値で割った数になります。

トランザクション処理数

単純にページ数やヒット数に着目するだけでは正確にサーバー側の負荷量との関係が測れない場合があります。

例えばユーザーのログイン処理や、購入アクションの処理等で他のページ処理と比べて異常に処理量が多く、サーバー負荷が高くなる場合があります。

このようなケースでは予めログインや購入処理に特化した短いシナリオを用意して、最大でこのログインや購入のアクションが時間内に何回行うことが出来るか測定する方法もあります。そして、このシナリオ=トランザクションの処理数をもって、想定した環境(ユーザーが一斉にログインする/購入処理を行う)でのサーバーの処理能力の上限と判定することが出来ます。

トランザクション処理数を指標とすることのメリットは単純に訪問者数と等しいものとして読み替えることが出来ることです。

しかし、アクセス統計の一人あたりのヒット数やページ数の平均値がこのシナリオのページ数やヒット数と異なる場合には、結果からのサーバーの処理能力の見積もりとしては、不正確な値が得られてしまうことがあるために注意が必要です。

仮想ユーザー数の意味

Oracle Load Testingや各種負荷テストツールは、負荷の生成量に仮想ユーザー数(同時接続ユーザー数)という概念を使用しています。

この指標は、お客様やマーケティング部門の担当者が知りたいような、一定時間内に訪問するユーザー数の合計とは関係無く、純粋にユーザーコネクションの数を示しているに過ぎません。具体的には、同じタイミングで、同時に何名のユーザーがシステムに対して接続している状態になっているかという指標であり、リクエスト中以外のアイドル状態(シンクタイム)のユーザーも含みます。

TCPのコネクションレベルでは1ユーザーあたり、数本のコネクションを使用したりもするため、あくまでもユーザーレベルのコネクションのカウントになります。

仮想ユーザー数と負荷

ユーザーのシンクタイム(リクエストをせずに閲覧している状態)が通常のユーザーアクセスでは存在し、その長さは通常3秒から数十秒程度になります。

もし、このシンクタイムが少なければ、同じ仮想ユーザー数であっても、システムに対するリクエストの頻度は頻繁になり、秒間あたりのサーバー側の処理数も増加し、システム負荷が高くなります。つまり、サーバーの性能測定において、仮想ユーザー数単体では指標として意味が無く、シンクタイムつまりページ間の遅延や、訪問間隔(反復間遅延)を含めて算出することで、どの程度の負荷をサーバーに掛けることが出来るのか予測することが出来る訳です。

以下の式になります:

 負荷量(時間あたりで処理出来たページ数) = 

(仮想ユーザー数 × (ページ間または反復間遅延+サーバー側応答処理時間))/実行時間

例えば、ページ間遅延、反復間遅延を4秒として、サーバー側の平均処理時間が1秒の場合、1仮想ユーザーあたりでは5秒間に1ページのやり取りが行われることになり、秒間0.2ページのリクエストになります。

もし、仮想ユーザー数として1000仮想ユーザーが使用可能ならば、秒間あたり最大200ページ/秒までの負荷を掛けることが出来るということになります。

ページ間遅延、反復間遅延を狭める際の注意点

もし、ページ間や反復間の遅延をより少ない時間に設定した場合には、より多くの負荷をサーバーに掛けることが出来るようになります。

例えば上記の例で、ページ間、反復間遅延を2秒にすると、1000仮想ユーザーでは、最大で333ページ/秒の負荷を掛けることが出来ます。

ただし、遅延時間を0秒にして純粋にサーバー処理時間のみに指定した場合で、サーバーの応答時間が速い場合には、クライアント側のリクエストや解析処理が逆にボトルネックとなって、正確なサーバー処理時間の計測値が得られなくなりますので、かならず遅延時間は入れた上で計測しましょう。

また、サーバー側の負荷を上げようとして、仮想ユーザー数は増やさずに、ページ間、反復間遅延時間だけを狭めようとすると、時間あたりのページ数は増加したとしても、以下の理由で正確なテスト測定値となりえない場合があります。

* アプリケーションサーバー側のメモリ量

特にアプリケーションサーバーでは、ユーザー毎にセッション情報のオブジェクトを作成して保持しようとする場合があります。この際にテスト時の同時ユーザー接続が現実のケースよりも少ないと、例えリクエスト数は多くとも、メモリ確保量は現実ほど大きくならず、システムのメモリ使用状態の計測については不正確なテスト結果となってしまう場合があります。

* 同時コネクション数

Webサーバーやロードバランサ-、ファイアーウォールでは、TCPのソケットやSSLセッションの上限値が存在し、それ以上の接続要求が来た場合には遅延現象を起こす仕組みが一般的です。 この際に現実より少ない仮想ユーザー数で実施した場合には、テスト時にこのコネクション数の問題点を見落としてしまう可能性があります。

サーバー応答時間や、CPU使用率

負荷計画立案時には、仮想ユーザー数や遅延時間の指定のもとで、どの程度のページ処理を行わせるか予測を立てて実施することが出来ますが、1点だけ、予測不可能な指標として、サーバー側の応答処理時間があるために、予想通りの処理量は達成できなくなることがあります。

もちろん、その現象を確認するために性能試験を行う意義が存在します。サーバー応答時間については、出来る限り、目標値(8秒等)を事前に定義しておき、その応答時間を超えた場合には一旦テストを打ち切る等の判断をすべきでしょう。また、CPU使用率が100%の上限に張り付いてしまうこともシステムの限界への到達を示しますが、その際にも所定時間以内で応答を返すことが出来るシステムは存在しますので、あくまでも二次的指標として、応答時間を第1にして観測しましょう。

まとめ

以上の通り、テストの結果計測値からのシステムの処理能力を測定する基準としては、秒間あたりのヒット数またはページ数が、客観的な指標となりやすく望ましいものであると考えられます。

一方、テスト実施前の計画段階で、テストツールで発生させる負荷の量の見積もりでは、設定定義可能な指標としての、仮想ユーザー数を基準に考えることになります。

上述のように、ユーザーのシンクタイムやサーバー応答時間が常識内の範囲(シンクタイムが10秒程度、応答時間が5秒以内)という前提があるのならば、以下のような形で必要な仮想ユーザー数を見積もることが出来るのではないかと考えられます。

<例1>

1時間あたりの訪問者目標: 

2000人

1シナリオあたりのページ数:

15ページ

 →目標ページ数 30,000ページ = 秒間あたり8.3ページが目標値

シンクタイム平均10秒、応答時間5秒 = 15秒/ページ = 秒間0.0667ページ(1VUの場合)

→ 目標値秒間ページ数 8.3 / 0.0667 = 123.43 -> 約124VUが必要

結論: 上記の2000人/時間の訪問者数のアクセスを再現するには124VUが必要

<例2>

1時間あたりの訪問者目標:

10000人

1シナリオあたりのページ数:

8ページ

 →目標ページ数 80,000ページ = 秒間あたり22.22ページが目標値

シンクタイム平均7秒、応答時間3秒 = 10秒/ページ = 秒間0.1ページ (1VUあたり)

→ 目標値秒間ページ数 22.2 / 0.01 = 222 -> 約222VUが必要

結論: 上記の10000人/時間の訪問者数のアクセスを再現するには、222VUが必要

8. 負荷テストアプローチ別の目標設定と指標の考え方  に進む