I Can't Stress It Enough － ASP アプリケーションのロードテスト

[アーティクル]
11/25/2008

J.D. Meier
Microsoft Corporation

September 27, 1999

この記事は、もともと MSDN Online Voices のコラム "Servin' It Up" に掲載されたものです。

はじめに

従来のクライアント/サーバーアプリケーションから Web 空間に移行するとき、スケーラビリティとパフォーマンスに対する需要の増大に応えなければならないことに気がつきます。最大の課題の 1 つは、あなたのアプリケーションが何人のユーザーをサポートできるかを調べることです。あなたは、どのようにこの課題に立ち向かいますか？手始めとしては、明確なパフォーマンス目標を設定して、Web ストレスツールを使用するのがよいでしょう。

この記事は、Active Server Pages (ASP) アプリケーションのストレステストの紹介であると同時に、Microsoft の Web Application Stress Tool の紹介でもあります。以下の段落では、ストレステストの基本を説明するとともに、より効率的なテストを行い、テスト結果に基づいてアプリケーションを変更するためのヒントを述べます。

シナリオ

あなたは予想ユーザーベース 1,000 人に対して ASP アプリケーションを導入しようとしています。このアプリケーションは少なくとも 2 人の同時ユーザーを処理できることがわかっています。なぜなら、あなたとあなたの相棒が 1 日中使い倒しても、パフォーマンスの低下は起きていないからです。あなたは、2 人のユーザーだけで、負荷の下でのアプリケーションの動作が正確にわかるものだろうか、と疑問に思いました。標準的なパフォーマンステスト (楽観して、とりあえずアプリケーションをリリースしてしまうという方法) はいつでも利用できますが、あなたのアプリケーションのスケーラビリティをあらかじめ調べておくことにしました。

テストの要件を決める

ASP アプリケーションに適切なストレスをかけるには、まず、あなたのアプリケーションがどの程度の負荷に耐えられるのか調べる必要があります。単純にするために、負荷は次のような数値として分析することができます。

ユーザーベース (このアプリケーションの合計ユーザー数は？通常、この数は、1 日、1 週間、または 1 か月あたりのユニークヒット数で捉えられます。おそらく、1 時間あたりのユニークヒット数など、より管理しやすい数にすることもできます。)
同時ユーザー数 (ピーク時の最悪のシナリオは？それに備えてください。力をあてにすることは、力を使うことと同じように有効です。)
ピーク要求レート (1 秒間にいくつの ASP ページを実行する必要があるか？これは、ASP アプリケーションがユーザーに応答する能力を測定するとき、おそらく最も重要なファクターです。)

アプリケーションが実際に使用される前にアプリケーションの合計ユーザー数と同時ユーザー数を調べるのは難しいことです。インターネットアプリケーションの場合は特にそうです。イントラネットアプリケーションでさえ、「潜行性のユーザー増加」(user creep) に直面する傾向があるので、その利用量を正確に予測するのは困難です。どこから始めたらよいかわからないときには、次のような基本事項から始めてください。

インターネットに関する考慮事項:

既存の Internet Information Server (IIS) ログを分析します。数値は現実的な確率を示すかもしれません。
あなたのサイトは、実際のところ、どれぐらい人気が高くなりそうですか？人気が高いサイトは、1 日に 100 万以上のヒット数を記録することがあります。そこまでは行きそうもないですか？では、さまざまなシナリオで "what if" を考える必要があります。もし、ユーザーベースが 1,000 人だったら？あるいは 10,000 人だったら？問題が発生してからハードウェアを増設することによってスケーラビリティ問題を解決できますか？それとも、それができないようなアプリケーションアーキテクチャですか？
最悪のシナリオは何ですか？あなたの友人たちに最悪の事態が起きるかどうか尋ねてみてください。

イントラネットに関する考慮事項:

やはり、既存の IIS ログを分析します。
この ASP アプリケーションは、全員を対象としたものですか？企業イントラネットには何台のマシンがありますか？システム管理者たちは、ピーク時のネットワークトラフィックを把握していますか？
そのアプリケーションの対象者は限定されていますか？人事部だけですか？人事部の部員は何名ですか？
最悪のシナリオは何ですか？

負荷を予測できない場合は、アプリケーションの上限を調べておくことが最良の策かもしれません。10 人のユーザーがヒットした場合、1 秒間にいくつの ASP 要求に応えることができますか？ 100ですか？ 1,000ですか？ 10,000ですか？ベンチマークを記録してください。実際の使用のトラフィックログがあなたの限界に近づいてきたとき、現在の限界がわかるというだけでなく、解決策を準備する時間もあるでしょう。

Web Application Stress Tool の紹介

ストレスツールはいろいろありますが、この記事では Microsoft の標準的な Web ストレスツールとなっている Web Application Stress Tool (旧称 Homer) をご紹介します。WebCat を使い慣れている人は、Web Application Stress Tool の既存の WebCat スクリプトをインポートできる機能を評価するでしょう。 InetMonitor を使ったことがある人は、Web Application Stress Tool も GUI ベースであることを評価するでしょう (多くのユーザーにとって、これはコマンドライン方式の WebCat に対して大きな利点です)。もう 1 つの特典は、それが無料だということです。私の友人はいつも、「無料なら、それは私向き」と言っています。その魅力的な価格に加えて、このツールはかなり広範囲の機能を特長とし、さらに進化し続けています。Microsoft.com はこのツールを多用しているので、その重要性を理解しています。

しかし、私の言葉を鵜呑みにせずに、あなた自身で試してみてください。この記事の末尾にサードパーティ製ストレスツールのリストがありますので、あなた自身で結論を引き出してください。とにかく、ASP アプリケーションを負荷にさらして、リリース前にアプリケーションをチューニングするためのツールが必要です。

Web Application Stress Tool 入門

初めてこのツールを使用して ASP ページをテストする場合の手順を説明します。また、認証の使用と複数ユーザーのテストについても説明します。これらの問題は、Web Application Stress Tool を初めて使用する人々をとまどわせることがあるらしいからです。

まず、最初のステップは、Web Application Stress Tool のダウンロードとインストールです。MS Web Application Stress ツールから、このツールの最新版を入手することができます。このサイトにはチュートリアルも用意されているので、必要に応じてご覧ください。

インストールについて注意すべき点がいくつかあります。

Web サーバー自身に Web Application Stress Tool をインストールしないでください。より正確なテスト結果を得るために、別のマシンにインストールしてください。
Web Application Stress Tool を実行するマシンには、ActiveX Data Objects (ADO) バージョン 2.1 以上がインストールされている必要があります。oledb32.dll がバージョン 2.10.3711 以上でない場合、ADO は Web Application Stress Tool インストーラによってインストールされます。
インストール時にインストールログが作成されます。インストールログは、デフォルトでは \Program Files\Microsoft Web Application Stress Tool\INSTALL.LOG です。
以前のバージョンの Web Application Stress Tool がインストールされていた場合、アップグレードしてもデータファイルは保持されます。Web Application Stress Tool は、Access の .mdb ファイルをデータストアとして使用します。Web Application Stress Tool に同梱されているオリジナルの .mdb は WAS.mdb であり、アプリケーションのインストール先ディレクトリにあります。
Web Application Stress Tool は、情報を次のレジストリキーに格納します。HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WAS

新しくインストールした Web Application Stress Tool を起動する前に、テスト用の単純な ASP スクリプトを作成しましょう。MyASPPage.asp という名前の新しい ASP ページを作成して、下記のスクリプトを挿入します。

                  

MyASPPage.asp
<%@ Language=VBScript %>
<HTML>
<BODY>
<%  CONST ForAppending = 8
  set oFSO = server.CreateObject("Scripting.FileSystemObject")
  ' 仮想ディレクトリを物理パスに変換する
  strFilePath = Server.MapPath(Request.ServerVariables("PATH_INFO"))
  ' 仮想ディレクトリのルートを取得する
  strFilePath = left(strFilePath, (InstrRev(strFilePath, "\")))
  strFilePath = strFilePath & "MyFile.txt"
  ' ファイルのフルパスを画面に表示する
  Response.Write(strFilePath & "<BR>")
  set oTS = oFSO.OpenTextFile(strFilePath,ForAppending, true)
  oTS.writeline("Session Id: " & Session.SessionId & chr(32) & _
      "Time: " & Cstr(now()))
%>
</BODY>
</HTML>

このスクリプトは、SessionId と、その動作時間をテキストファイルに書き出します。それによって、ASP ページが正しく実行されていることを簡単に検証することができます。ツールに慣れたら、あなたの本当の ASP ページを実際にテストすることができます。

ASP ページを、匿名アクセスが可能な Web サーバー上のディレクトリに落とし込んでください。この記事の後の方で認証が必要な場合について説明しますが、とりあえず基本的なテストを実行してみましょう。サーバー名も含めたフル URL を使用して、新しい Web ページをブラウズします。たとえば、フル URL は、http://MyServer/MyVirtualDirectory/MyASPPage.asp のようになります。うまく ASP ページをブラウズできたら (MyFile.txt が仮想ディレクトリの物理位置に書き込まれていることを確認します)、Web Application Stress Tool を起動します。

Web Application Stress Tool を起動すると、次のようなダイアログボックスが表示されます。

Dd313983.createnewscript(ja-jp,MSDN.10).gif

図 1. 新しいスクリプトの作成

他のオプションもおもしろそうですが、今は [Manual] を選択してください。後で、メニューバーから [Scripts] を選択するか、ツールバーの [New Script] アイコンをクリックすることによって、新しいスクリプトを作成することもできます。

スクリプトビューへようこそ。左側のぺインは、スクリプトのツリービューです。右側のぺインで、スクリプト設定を変更します。Web Application Stress Tool の使い勝手がわかってきたら、変更したいオプションを直接クリックしてください。それまでは、1 つずつ見ていきましょう。

左側のぺインのツリービューから [New Script] をシングルクリックすると、スクリプトビューが起動します。 [Server] テキストフィールドにサーバーの名前を指定します。最初の [Script Item] で、[Verb] として GET を選びます。[Path] フィールドに、ASP ページの URL を仮想ディレクトリから入力します。下の図 2 を参照してください。

Dd313983.scriptsdetail(ja-jp,MSDN.10).gif

図 2. [Path] フィールドに URL を入力する

この時点で、ツールバーの [Run Script] 矢印をクリックして、スクリプトを実行することができます (左側のぺインで正しいスクリプトが選択されていることを確認してください)。スクリプトは約 1 分間で終了して、パフォーマンスのサマリーレポートが生成されるはずです。

結果の分析

生成されたレポートを表示するには、ツールバーの [Reports] アイコンをクリックします。[Script] タブの隣に新しいタブ ([Reports]) が作成されます。レポートはアウトラインビューで格納されます。最初に、レポートの下の [Result Codes] 情報を確認してください。テスト中に何か問題があったかどうかが一目で分かります。200 以外のステータスコードが表示されている場合には、おそらく何が問題かを調査しなければなりません。よくある問題としては、認証と、誤ったURL があります。

特定のレポート下の [Overview] をクリックすると、テスト活動の簡単な内訳を表示することができます。ASP テクノロジの見地からすると、[Reports] の [Overview] セクションにある Requests per Second は、チェックすべき主要な統計値の 1 つです。この数値は、高いほど良い結果を示しています。一般に、使用レポートと見積もりに基づいて具体的な目標を決めることができなかった場合、データベースをヒットしたり、何もコンポーネントを使用していない ASP ページでは、Requests per Second は、通常 30 以上でなければなりません。当然ながら、データベースのヒットはアプリケーションに対するオーバーヘッドを増加させます。

ASP に関する Requests per Second カウンタはデフォルトで Web Application Stress Tool に含まれていますが、他のカウンタを追加することもできます。カウンタを追加するには、スクリプトの下の [Perf Counters] アイコンをクリックした後、[Add Counter] をクリックします。特に有用なカウンタは、ASP に関する Requests Queued です。このカウンタは、処理をブロックしていたり、実行に時間がかかっているページまたはコンポーネントを識別する鍵となります。ASP パフォーマンスの分析については、以下の資料に詳しい説明があります。

Tuning Internet Information Server Performance
Navigating the Maze of Settings for Web Server Performance Optimization
Microsoft Internet Information Server リソースキット

パフォーマンスとスケーラビリティに影響を与える要因

サーバーコンポーネント、データベースアクセス、およびその他の要因によって、ASP の Request per Second 数が激減することがあります。各種の構成オプションもそれに一役買うことがあります。ここでは、最も一般的な要因をいくつか挙げておきましょう。

データベースにアクセスしている場合、接続をプールしていますか？プーリングの詳細については、「Pooling in the Microsoft Data Access Components」を参照してください。
ASP Session 変数を使用して、状態を格納していますか？ Session 変数は、短時間でスケーラビリティを制限することがあります。それらはサーバーリソースを必要とし、スケーリング問題に直面してもマシンの増設を不可能にします。Session は特定のマシンに関連付けられるからです。最大のスケーラビリティを得るには、ステートレスでなければなりません。Session に代わる機能については、「HowTo: Persisting Values without Session 」を参照してください。
Visual Basic® コンポーネントをセッションステートに格納していますか？そのような場合は、今すぐ削除することを考えたほうが良いでしょう。Session 内の Visual Basic オブジェクトはスレッドアフィニティの原因となり、IIS のスレッドプールの本来の目的を無効にします。これは複雑な問題ですが、ある経験則を述べれば十分でしょう。それは、「シングルスレッドアパート (STA) オブジェクトを Session に格納してはならない」ということです。Session でオブジェクトを保持する必要がある場合は、"Both" としてマークして、フリースレッドマーシャラを集成する必要があります。Active Template Library (ATL) を利用すると、そのように動作するものを作ることができます。
あなたの Web アプリケーションは独自のメモリ空間で実行するように設定されていますか？プロセス保護のために、このようにすることが推奨されています。しかし、極限までパフォーマンスを絞り出す必要がある場合は、Web アプリケーションをプロセス内で実行することによって、クロスプロセスマーシャリングのオーバーヘッドを節減することができます。
Microsoft Transaction Server (MTS) コンポーネントが使用されているときには、コンポーネントがサーバーパッケージとして実行する場合とライブラリパッケージとして実行する場合とでパフォーマンスに大きな差が生じます。一般的な推奨は、Web アプリケーションを独自のメモリ空間で実行するように設定して、MTS コンポーネントをライブラリパッケージとして実行します。

さらに詳しく知りたいですか？パフォーマンスとスケーラビリティの要因についての追加情報は、以下の記事を参照してください。

パフォーマンスとスタイルに関する ASP 15 のTips
Server Performance and Scalability Killers
Maximizing the Performance of ASP
Agility in Server Components

複数ユーザーのシミュレート

複数のユーザーをシミュレートするための Web Application Stress Tool のセットアップ方法について簡単に説明します。2 つのことをする必要があります。

[Settings] パネルの [Concurrent Connections] オプションを変更します。
スクリプトの [Users] 設定で、少なくとも [Concurrent Connections] オプションで指定したユーザー数と同じ数のユーザーを作成します。

同時ユーザー数を変更するには、スクリプトツリーのスクリプトの下の [Settings] アイコンをクリックします。最大 100 人のユーザーについて、[Stress Level] オプションを直接設定することができます。100 人を超えるユーザーをシミュレートするには、[Stress Multiplier] も設定しなければなりません。基本的な式は、ユーザー数 (スレッド数) = Stress Level * Stress Multiplier です。1,000 人のユーザーをシミュレートするには、Stress Level を 100 に、Stress Multiplier を 10 に設定します。

[Users] 設定で十分な数のユーザーを設定せずにスクリプトを実行しようとすると、警告メッセージが表示されます。ユーザー数を変更するには、スクリプトツリーのスクリプトの下の [Users] アイコンをクリックします。右側のぺインに [Default] グループが表示されます。[Default] グループをダブルクリックすると、ユーザーリストが表示されます。匿名アクセスを許可している場合は、必要な新しいユーザー数を入力して、[Create] をクリックします。

認証を必要とするテストの実行

認証を必要とするページに対してテストを実行する場合には、Web Application Stress Tool が実行時に使用する適切なユーザー名とパスワードを作成する必要があります。これも [Users] 設定から行います。まず、[Remove All] をクリックして、現在のユーザーリストを削除します。それから、ユーザーを追加します。テキストファイルからユーザー名とパスワードをインポートすることもできます。

いずれにしても、これらのユーザーは有効なアカウントである必要があり、IIS マシンにアクセス可能でなければなりません。基本認証を使用する場合は、資格証明を渡すことによって、ブラウザからすばやくアカウントをテストすることができます。また、確認のために Request.ServerVariables("AUTH_USER") の値をテキストファイルに書き出すとよいでしょう。変更後の ASP コードは次のようになります。

                  

  oTS.writeline("Session Id: " & Session.SessionId & chr(32) & _
       "Time: " & Cstr(now()) & "AUTH USER: " & chr(32) & Request.ServerVariables("AUTH_USER"))

Web Application Stress Tool に関するヒント

最後に、簡単なヒントを述べておきましょう。

短時間で大きくなるので、Web サイトのログファイルの格納領域を調整してください (IIS ドキュメンテーションを参照)。
下記の DWORD を 1 に設定することによって、デバッギング目的のために Web Application Stress Tool の活動を追跡することができます。 HKEY_LOCAL_MACHINE\Software\Microsoft\WAS\SessionTrace
Web Application Stress Tool のレポートにエラーが示されていた場合は、イベントログをチェックして、ツールの外部でページをブラウズして、Web サーバーのログ \WinNT\system32\LogFiles\W3SVCi をチェックしてください。
クライアントテストマシンのプロセッサ使用率が 85 % を超える場合は、おそらくクライアントマシンを増やす必要があります。
さらに詳しくは、Web Application Stress Tool のドキュメンテーションの以下のトピックを参照してください。Page Groups、Query Strings、Cookies、Web Application Stress Object Model、および Active Server Page Client (クライアントのテストを Web 経由でリモート制御することができます)。

このツールはサポートされていないツールであることに注意してください。質問は英文で webtool@microsoft.com にお送りください。Web Application Stress Tool Web サイトの左側のフレームにある [Search Knowledge Base] をクリックすると、Knowledge Base で HOWTO と既知の問題を探すことができます。このツールをプログラムすることもできます。同じサイトに参考用のオブジェクトモデルがあります。

参考資料

詳細については、Web Application Stress Tool Web サイトのチュートリアルをご覧ください。また、このツールに付属のオンラインヘルプの「Getting Started」セクション、特に「Web stress testing overview」をお読みください。

WebHammer 。Web アプリケーションとサーバーをテストする ServerObjects 社のツール。
LoadRunner 。エンタープライズレベルのアプリケーションのシステム動作とパフォーマンスを予測する Mercury Interactive 社のロードテストツール。
Enterprise Monitor 。イントラネットとインターネットネットワークの監視、通知、および回復を行う MediaHouse Software 社のツール。
Extreme Soft's PerfMon 。パフォーマンスモニタから直接 MTS を監視するための Microsoft Transaction Server 用のツール。

これでおしまい

では、次回までお元気で、ペプシ (または、シアトルに住んでいる方は latte) を飲んで！

J.D. Meier は米国東海岸で生まれて育ちました。Horace Greeley の助言に従って、MTS および ASP 技術を含むサーバー側コンポーネントと Windows DNA アプリケーションを専門とするデベロッパサポートエンジニアとして働いています。

I Can't Stress It Enough － ASP アプリケーションのロード テスト