IBM SmartCloud Enterprise での UI のパフォーマンスを測定する

フレームワークと Fiddler を使用してパフォーマンス自動測定システムを構築する

Web アプリケーションのユーザー・インターフェース (UI) のパフォーマンスを調整する場合、2 つの難題があります。1 つは特殊なリクエストに対する詳細なパフォーマンス・メトリックをどのようにして自動的に対象として設定し、結果を取得するかという問題であり、もう 1 つはユーザー・エクスペリエンスを基にページのパフォーマンス・メトリックをどのようにして正確に計算するか、という問題です。この記事では、そうした難題に対する答えとして、Web デバッグ用のプロキシーである Fiddler を活用した UI パフォーマンス自動測定システムを構築するために使用できる IBM SmartCloud Enterprise 用フレームワークを紹介します。また、このフレームワークと Fiddler に加え、この UI パフォーマンス自動測定システムによって測定されるパフォーマンス・メトリックについても紹介し、それらが UI パフォーマンスの測定にとっていかに重要であるかを説明します。

Yu Tong Li, Software Developer and Tester, IBM

Yu Tong Li はソフトウェアの開発とテストに 4 年間の経験があります。彼の担当は、さまざまなプラットフォームのためのテスト・ツールの開発、Web ベースの自動化フレームワークの開発、オープンソースの二次開発とパフォーマンス技術などです。彼は 2010年から IBM で働いており、これまで 5 本の記事を執筆し、また 2 つの特許を保持しています。



2012年 2月 23日

Web アプリケーションではユーザー・インターフェース (UI) のパフォーマンスが非常に重要です。UI のパフォーマンスは、ユーザーである顧客が Web アプリケーションの (そしてクラウドの) 一部として実際に経験するパフォーマンスです。ユーザー・エクスペリエンスの質が悪い場合には、ユーザーの不評を買い、顧客はその製品を購入しようとしません。

私は IBM SmartCloud Enterprise のパフォーマンス・エンジニアとして、完全に自動化された UI パフォーマンス測定用のフレームワークを開発しました。このフレームワークを利用すると、以下のような専門家レベルの測定を行うことができます。

  • ページ・ベースのパフォーマンス・メトリック測定
  • 必要なリソースの監視と統計情報の取得
  • ネットワーク帯域幅のシミュレーションと制御
  • 複数のパラメーター・ベースの機能制御

従来、これらの問題の多くは Web ベースのパフォーマンス監視ソフトウェアによって対応されてきました。しかしそれでも相変わらず以下の 2 つの大きな難題があり、この難題への対応が求められています。

  • 難題 1: 特殊なリクエストに対する詳細なパフォーマンス・メトリックをどのようにして自動的に対象として設定し、結果を取得するか
  • 難題 2: エンド・ユーザーのエクスペリエンスを基にページのパフォーマンス・メトリックをどのようにして正確に計算するか

難題 1 の例として、IBM Cloud のコントロール・パネル・ページには、getInstancesgetAvailableImagesgetAvailableStorage という 3 つの RPC リクエストがあります。この 3 つは最も重要なリクエストであり、これらのリクエストがページのパフォーマンスのボトルネックとなる可能性があります。このため、これらの RPC リクエストのパフォーマンス・メトリックを毎日または毎週評価し、レポートする必要があります。

これを一般的な要件として考えると、パフォーマンスを評価する対象として特殊なリクエスト (上記の RPC など) をすべて検出して対象に設定し、パフォーマンスの詳細を取得あるいは計算する自動モジュールが必要です。特殊なリクエストの例としては、以下のようなものが挙げられます。

  • クライアントによるリクエストの開始
  • クライアントによるリクエストの終了
  • サーバーによるレスポンスの開始
  • サーバーによるレスポンスの終了
  • クライアントによるレスポンスの開始
  • クライアントによるレスポンスの終了

しかし、既存のサードパーティーのエンジンやツールのなかで、このレベルのパフォーマンスの監視を自動で行うためにそのまま使用できるエンジンやツールを見つけるのは困難です。これが難題として挙げた理由です。

では、私が難題 2 を挙げた理由は何でしょう。それは、一般的なソリューションの場合、ページの応答時間を計測しようとすると必ずページを完全にロードするまでの時間が計測され、その時間を各部分に分けることができないからです。しかし場合によると、完全にロードするまでの時間は問題ではなく、ある指定のリクエスト (開始リクエスト) から別に指定されたリクエスト (終了リクエスト) までの時間を測定したい場合があります。Web 開発者が継続的なコードの実行に要する時間の計算と、ライフ・サイクルのリグレッション・テストにおけるパフォーマンスの向上に重点を置きたいのであれば、開始リクエストから終了リクエストまでの時間は、パフォーマンスを調整する上で意味のある重要なメトリックとなります。

この記事の後の方で、このフレームワークがどのようにして、自動的にパフォーマンス・メトリックを設定して結果を取得し、開始リクエストから終了リクエストまでの時間を測定する、という難題に対処するかを詳細に説明します。その前にまず、このフレームワークについて説明し、続いて Fiddler との統合、フレームワークとクラウド環境とのやり取り、そしてフレームワークを IBM Cloud にインストールする方法について説明します。

自動フレームワークと Fiddler

では、この自動フレームワークの概要をアーキテクチャー・レベルで見てみましょう (図 1)。

図 1. アーキテクチャー・レベルで見た自動フレームワークの概要
アーキテクチャー・レベルで見た自動フレームワークの概要

ピンク色のモジュール「Fiddler As Proxy/Agent (Fiddler プロキシー/エージェント)」の外側にあるものが、実装されたフレームワークのプロトタイプです。このプロトタイプをフレームワーク全体のメインストリームと呼ぶことにします。

では、「Fiddler As Proxy/Agent (Fiddler プロキシー/エージェント)」の中にあるものを見てみましょう。Fiddler 側の詳細をよく理解するために、図 2 を見てください。

図 2. 「Fiddler As Proxy/Agent (Fiddler プロキシー/エージェント)」コンポーネントの内部
「Fiddler As Proxy/Agent (Fiddler プロキシー/エージェント)」コンポーネントの内部

この図には、フレームワークのメインストリームとのやり取り、そして Fiddler のルールの上書き方法が表現されています。詳細については後ほど説明します。ここではまず、Fiddler について、また Fiddler とフレームワークとの統合について調べてみましょう。

  • Fiddler は Web デバッグ用のプロキシーであり、コンピューターとインターネットとの間のすべての HTTP トラフィックと HTTPS トラフィックをログに記録します。
  • Fiddler を使用すると、すべての HTTP/HTTPS トラフィックを調べることや、ブレークポイントを設定すること、受信データや送信データを操作することができます。
  • Fiddler はリクエストとレスポンスをログに記録します。そのため、そのログを基に、何が適切に動作しており、何が動作していないのかを判断することができます。

Fiddler にはイベント・ベースの強力なスクリプト・サブシステムが含まれており、任意の .NET 言語を使用して Fiddler を拡張することができます。図 3 はFiddler の UI の例を示しています。

図 3. Fiddler の UI の例
Fiddler の UI の例

Fiddler を使用すると、スクリプト・サブシステムを活用して、拡張機能を作成するためのコーディングをすることができます。スクリプトを編集するためには、メニューから「Rules (ルール)」 > 「Custom Rules (カスタム・ルール)」の順に選択します。スクリプトを保存すると、そのスクリプトは自動的にコンパイルされ、Fiddler にロードされます。スクリプトは Microsoft JScript.NET で作成され、Fiddler のオブジェクト・モデルに制限付きでアクセスすることができます。

Fiddler のデフォルト・ルールは \Program Files\Fiddler2\Scripts\CustomRules.js に保存されます。二次的なコーディングをする際はすべて、このファイルを上書きします。例えば、Fiddler の UI にカスタムの列を追加しようとする場合や、ハッキングなどの異なる目的で Web リクエストまたは Web レスポンスを変更する場合、あるいは Fiddler のメニューを変更する場合には、このファイルを上書きします。

単純な例として、すべての Web レスポンスに対して一連のストリングを検索し、指定された customcolumn にその結果を表示するために、CustomRules.js の OnBeforeRequest に以下のコードを追加することができます。

oSession.utilDecodeResponse();

// Create a array of strings we're looking for.
var oFindStrings = new Array( "XMLHttp", "onreadystatechange", "readyState", 
 "responseBody", "responseText", "responseXML", "statusText", "abort", 
 "getAllResponseHeaders", "getResponseHeader", "setRequestHeader");

// For each target string, check the response to see if it's present.
var iEach=0;
oSession["ui-customcolumn"]=String.Empty;
for (iEach; iEach<oFindStrings.length; iEach++){
    if (oSession.utilFindInResponse(oFindStrings[iEach], false)>0) 
      {
      oSession["ui-color"]="purple";
      oSession["ui-customcolumn"] += oFindStrings[iEach]+"; ";
    }}

要件を思い出してください。必要なものは、Fiddler とユーザー (つまり任意のモジュール (自動プログラムなど)) とがやり取りするためのインターフェースです。そのためには、バッチ・ファイルやユニット・テストからの呼び出しに適したコマンドライン実行プログラムである Fiddler の ExecAction.exe を使用します。

Fiddler の制御や Fiddler とのやり取りを含め、自動化に利用できるインターフェースはこのコマンドのみです。なぜなら、このコマンドは Fiddlerの QuickExec ボックスと同じように、コマンドラインを FiddlerScript の OnExecAction 関数に渡して処理を行うからです。

例えば、難題 1 の Fiddler 側を実装し、ビルド検証テスト (BVT: Build Verification Test) を実現するとしましょう。コマンドがトリガーされた場合に何が起こればよいのかを Fiddler が理解できるように、rpcExecAction.exe のパラメーターとして設定します。すると、Fiddler の QuickExec ボックスに ExecAction rpc と入力するだけでよくなります。

このコマンドを外部の自動プログラムから呼び出すためには、システム変数に .exe パスを設定して DOS コンソールで実行するだけでよいのです。例えば AutoIt の場合は _RunDos("ExecAction rpc") という 1 行のコードのみです。

難題 2 の場合もプロセスは同じです。任意のものをパラメーター (calc_cp) として使用することができ、AutoIt では _RunDos("ExecAction calc_cp") を使用してそのパラメーターを呼び出します。


難題の詳細

一般的な Web アプリケーションでは、画像や、JavaScript、CSS などを要求したり、アプリケーションの呼び出しなどを要求したりする、さまざまなタイプのリクエストがあります。分類された各リクエストに対する詳細な情報とパフォーマンス・メトリックが得られると、必要に応じて詳細にパフォーマンスを調整することができます。

IBM Cloud の場合、コントロール・パネル・ページ上の重要なリクエストとして、getInstancesgetAvailableImagesgetAvailableStorage という 3 つの RPC リクエストがあります。

getInstances リクエストは、現在のユーザーが使用中のすべてのインスタンス (実際には仮想マシン) に関して必要な詳細情報を取得し、テキスト/JSON オブジェクトを返すように設計されています。図 4 は getInstances RPC を示しています。

図 4. getInstances RPC
getInstances RPC

図 5 は、図 4 の JSON から変換されたメトリックの一部を、手を加えていない変換後の状態で示しています。

図 5. テキスト/JSON オブジェクトに手を加えていない状態のメトリック
テキスト/JSON オブジェクトに手を加えていない状態のメトリック

このリクエストの場合、現在の顧客アカウントには 12 インスタンスしかロードされておらず、受信したのは 15,544 バイト (ヘッダーが 274 バイト、本体が 15270 バイト) のみです。インスタンスの数が増加するにつれ、返される情報が幾何学的に増加することを想像してみてください。そうした場合、以下のような点に関してリクエストがどれほどスケーラブルであるかがポイントになってきます。

  • 顧客が 1,000 インスタンスを保持している場合にどうなるか。
  • リクエストは 1 つの顧客アカウントの下で利用可能な最大インスタンスにも対応できるほどスケーラブルか。
  • 非常に大量の情報が返される場合にボトルネックがあるか。
  • そうしたことが発生すると、パフォーマンスのパラメーターにどんな影響があるか。

これらの疑問に答え、潜在的な問題を回避するためには、何よりもまず、ライフ・サイクルにおけるリグレッション・テストの中で getInstances リクエストを測定、追跡できなければなりません。可能な限り詳細なメトリックを取得し、同一条件での比較ができるようにする必要があります。

では難題 2 についてはどうでしょう。UI のパフォーマンスを調整する場合、なぜ開始リクエストから終了リクエストまでの時間が重要なのでしょう。

この要件は、ページの応答時間をどのようにして正確に計算するか、という問題でもあります。通常はツールを使用することで、1 つのページを完全にロードするまでの時間を測定することができます。しかし場合によると、そうしたメトリックは必要なく、指定されたリクエストから別の指定されたリクエストまでの応答時間を測定したい場合があります。

通常こうした状況が生じるのは、Web 開発者が行ったコードの変更が有効であるか否かを確認または評価しようとする場合です。例えば IBM Cloud の場合、開発者がコントロール・パネルのページのパフォーマンスを向上させるコードを送信し、さらにページのロードに遅延ロード・パターンを適用した場合、開発者はある特定のリクエストを送信することで終了するページの応答に関し、応答時間のメトリックを取得する必要があります。それらのメトリックには、エンド・ユーザーのエクスペリエンスと、どの程度適切にコードが更新されているかが正確に反映されます (図 6)。

図 6. UI のパフォーマンス・チューニングには開始リクエストから終了リクエストまでの時間が重要です
UI のパフォーマンス・チューニングには開始リクエストから終了リクエストまでの時間が重要です

getInstances の呼び出しが成功すると、UI レベルのインスタンス・テーブルが表示されます。ユーザー・エクスペリエンスの観点から見ると、インスタンス・テーブルが表示された後、正確な実行時間を取得する必要があります。つまりパフォーマンスを正確に測定するためには、同じページ内で getInstances の後に呼び出される一連のリクエストを除外する必要があります。

では、このフレームワークがクラウド環境でどのように実行されるのかを調べてみましょう。


クラウドでのフレームワーク

このフレームワークにより、一般的な任意の Web アプリケーションの UI のパフォーマンスを調べることができます。

  • ブラウザーから独立した Fiddler 側から見ると、どのようなブラウザーでクラウドのフロント階層が実行されているかについては、何の制約もありません。
  • ドライバー側から見ると、このフレームワークの AutoIt で使用されている言語と同じ言語を使用することも、皆さんにとって使いやすい任意の言語を使用して独自のドライバーを作成することもできます。例えば、.Net プログラミングを使用して WatiN フレームワークを利用したり、Java プログラミングで Selenium を利用したりすることもできます。

もう一度図 2 を見てください。図の一番下に、コード・フローについて記述した 2 つの四角形が示されており、左側の四角形は難題 1 の要件 (requirement 1) を示しています。Fiddler 側を開発する場合のポイントは、十分なドキュメントがない中で、Fiddler フレームワーク内で Fiddler の CustomRules.js をどのように上書きするかという点です。Fiddler のルールを上書きすることによって以下の内容を実行します。

  • すべてのセッションを取得する
  • 各セッションをトラバースする
  • 条件に従って対象を特定する
  • 新しいセッション配列を割り当て、対象セッションを保存する
  • セッションをアーカイブに書き込む

下記は getInstances RPC を処理するためのコード・サンプルを抜粋したものです。

     var oSessions: Fiddler.Session[] = FiddlerObject.UI.GetAllSessions();
     var iSessions : Session[] = new Session[1];

     //[getInstances]for each session perform filtering:
     //if session's url equals '/cloud/enterprise/auth/cloud-rpc' && its request 
       body contains 'getInstances' : save the session to RPC_getInstance_id.zip
     for (var x = 0; x < oSessions.Length; x++)
     {
          
          if( (oSessions[x].PathAndQuery=="/cloud/enterprise/auth/cloud-rpc") &&
              (oSessions[x].utilFindInRequest("getInstances",true)>-1)     )
          {
               iSessions[0]=oSessions[x];
               Utilities.WriteSessionArchive(
                 "RPC_getInstances_"+oSessions[x].id+".saz",iSessions,"",true);
               FiddlerObject.StatusText = "Success dump the GetInstance PRC archive 
                 to RPC_getInstances_"+oSessions[x].id+".saz";
               break;

          }

     }

getAvailableImagesgetAvailableStorage の処理も同じ方法で行うことができ、上記のリストをテンプレートして使用することで、それぞれに対応するコードを容易に作成することができます。

もう一度図 2 を見てください。図の一番下に、コード・フローについて記述した 2 つの四角形が示されており、右側の四角形は難題 2 の要件 (requirement 2) を示しています。Fiddler のルールを上書きすることによって以下の内容を実行します。

  • すべてのセッションを取得する
  • 各セッションをトラバースする
  • 条件に従い、対象となる開始リクエストを検出する
  • clientBeginRequest の送信時刻とセッション ID を取得する
  • size=3 でストリング・リストを割り当て、その最初の項目として上記の時刻と ID を保存する
  • 条件に従い、対象となる終了リクエストを検出する
  • clientDoneResponse の送信時刻とセッション ID を取得する
  • この情報を 2 番目の項目として保存する
  • 開始リクエストから終了リクエストまでの時間を計算する
  • この情報を最後の項目として保存する
  • ストリング・リストを duration.txt に書き出す

IBM Cloud のコントロール・パネル・ページで開始リクエストから終了リクエストまでの時間を正確に計算するためのコード・サンプルを以下に示します。

//[cpbegin]for each session performs filtering:
//if sessions's url equals '/cloud/enterprise/user/control?csrftoken=': 
  record the ClientBeginRequest timestamp
for (var x = 0; x < o_calc_cp_allSessions.Length; x++)
{
   if( o_calc_cp_allSessions[x].PathAndQuery.Contains
     ("/cloud/enterprise/user/control?csrftoken="))
   {
      var cp_begin:String = o_calc_cp_allSessions[x].Timers.ClientBeginRequest;
      cp_b = new Date(o_calc_cp_allSessions[x].Timers.ClientBeginRequest);
      cp_array[0] = "Sid,"+o_calc_cp_allSessions[x].id+",ClientBeginRequest,"+cp_begin;
      FiddlerObject.StatusText = "the session indicating cp start is 
       successfully found, with Sid: "+o_calc_cp_allSessions[x].id;
      Break;
   }
}

//[cpend]for each session perform filtering:
//if sessions's url equals '/cloud/enterprise/auth/cloud-rpc' && 
  its request body contains 'getInstances' : record the ClientDoneResponse timestamp
for (var x = 0; x < o_calc_cp_allSessions.Length; x++)
{
   if( (o_calc_cp_allSessions[x].PathAndQuery=="/cloud/enterprise/auth/cloud-rpc")
    && (o_calc_cp_allSessions[x].utilFindInRequest("getInstances",true)>-1)
     )
   {
      var cp_end:String = o_calc_cp_allSessions[x].Timers.ClientDoneResponse;
      cp_e = new Date(o_calc_cp_allSessions[x].Timers.ClientDoneResponse);
      cp_array[1] = "Sid,"+o_calc_cp_allSessions[x].id+",ClientDoneResponse,"+cp_end;
      FiddlerObject.StatusText = "the session indicating cp end is successfully
       found, with Sid: "+o_calc_cp_allSessions[x].id;
      break;
   }

}
//try calc the duration
if(cp_b != null && cp_e !=null)
{
   var timePast : double = (cp_e - cp_b)/1000.00
   cp_array[2] = "Timepast,"+timePast;
   FiddlerObject.StatusText = "the time duration for cp is calculated 
    successfully: "+timePast;
}

var   myByteArray:byte[]  = System.Text.Encoding.UTF8.GetBytes
 (cp_array[0]+"\n"+cp_array[1]+"\n"+cp_array[2]); 

//write array to file by leveraging the built-in api.
Utilities.WriteArrayToFile(CONFIG.GetPath("Captures") + 
 "duration_cp.txt",myByteArray);

ドライバー側を開発する場合には、新しい Web サイトに合わせ、コードのどこを変更する必要があるのかを理解する必要があります。IBM Cloud の場合には Web ナビゲーションのためのページが 6 ページあります。そのため、開発者はコードを調べ、ページの ID をクラウド内で要求される ID で置き換える必要があります。例えば、図 7 は IBM Cloud のページの例として Account という ID のページを示しています。Account という ID を皆さんのエントリーと置き換えてください。

図 7. 独自のエントリーと置き換える
独自のエントリーと置き換える

新しいクラウドにフレームワークを適用するためには、Fiddler のスクリプトとドライバー側のコーディングを理解するだけでよいのです。クラウドのページに対する上記のサンプルを参照することで、皆さん独自のソリューションに対応させる方法を容易に理解できるはずです。


IBM Cloud 内でフレームワークを設定する

このフレームワークは完全なソリューションであるため、設定方法と使い方は簡単です。図 8 はその概要を示しています。

図 8. 設定を開始する
設定を開始する

設定を開始するための手順は以下のとおりです。

  • ソフトウェアのインストールに関しては、マシンに AutoITFiddler がインストールされている必要があります。
  • 構成の前提条件として、SystVarDependencyCheck.exe を実行し、このソリューションを実行できるようにシステムを自動更新します。Fiddler の実行可能ファイルのパスと、Fiddler のデフォルト・データのパスを追加します。初めて使用するユーザーのみ、これらを一度だけ実行する必要があります。
  • ドライバー側のバイナリーの概要は以下のとおりです。
    • Manager.exe は run2run コントローラーです。
    • UIIE_Fiddler_Shot_1.0.exe は基本プログラム実行用ドライバーです。
    • カスタマイズが必要な場合、ユーザーにとって必要でユーザーが編集できるインターフェースは baseline.properties のみです。
  • Fiddler 側のソース CustomRules.js は図 7 に表示されていませんが、コーディングによって Fiddler とやり取りするためのインターフェースは、この CustomRules.js です。更新されたフレームワークのファイルをローカルの Fiddler に上書きでコピーします。

ここで、このフレームワークを以下のシナリオでどのように使用するかを簡単に説明しましょう。UIIE_Fiddler_Shot_1.0.exe ファイル、Manager.exe ファイル、baseline.properties ファイルを皆さんのコンピューターに保存します。実行をカスタマイズするために使用できるインターフェースは baseline.properties のみなので、このファイルを編集します。

明確に理解できるように、プロパティー・ファイルのエントリーを以下に挙げておきます。

  • URL: クラウドの Web サイト
  • ServerAddress: Web アプリケーションがホストされるマシンの IP
  • User: ログインに使用する顧客のユーザー ID
  • PASSWORD: ユーザーのパスワード
  • CacheClean: ブラウザーのキャッシュを制御するためのフラグ (スイッチ)
  • SuccessCapacity: run2run セッションで要求される基本プログラムの実行成功回数
  • TotalExitCapacity: run2run セッションにおける基本プログラムの累計実行回数がこの値を超えると run2run セッションを終了します
  • BWEnable: 帯域幅のシミュレーションを有効にするためのフラグ (スイッチ)
  • BWIN: BWEnable を有効にして基本プログラムを実行する場合の TCP/IP でのダウンロード速度
  • BWOUT: BWEnable を有効にして基本プログラムを実行する場合の TCP/IP でのアップロード速度
  • Comment: 実行される基本プログラムの出力に追加したい任意のコメント

シナリオ: 基本プログラムを実行する

では最初のシナリオとして、基本プログラムを実行するための設定、基本プログラムの実行、そして実行結果の評価について順を追って説明しましょう。ページ・ベースのパフォーマンス・メトリック、リソースの使用状況のパフォーマンス・メトリック、ネットワークの使用状況のパフォーマンス・メトリックは、ドライバー側の UIIE_Fiddler_Shot_1.0.exe に組み込まれて実装されています。そのため、これらのメトリックを取得するために baseline.properties を構成する必要はありません。基本プログラムを実行しさえすれば、必ずこれらのメトリックを取得することができます。図 9 は基本プログラムを実行した場合の例を示すスクリーンショットです。

図 9. 基本プログラムを実行した場合の例
基本プログラムを実行した場合の例

例えば、「Base_AllRequests_09-06-2011-07-42-59_N」というサンプル・フォルダーを見ると、上記のように sys_metrics というディレクトリーがあり、その中には自動生成された以下の 4 つのファイルが含まれています。

  • cpu.tsv には CPU の使用状況に関する情報が記されています。
  • ping.log にはネットワーク遅延のメトリックが記録されています。
  • tracert.log には IP トレース・ルートの情報が記されています。
  • baseline.properties は、この基本プログラムを実行するための設定を示す情報が記されています。

RPC_getAvailableImages_SID、RPC_getInstances_SID、RPC_getAvailableStorage_SID というディレクトリーは、難題 1 の要件のためのものであり、対象とする 3 つの RPC リクエストに関する BVT の結果として生成されたものです。SID は、この基本プログラムを実行する中で発行されたリクエスト全体の中で何番目に当たるかを示すインデックス番号です。

duration_cp.txt ファイルは難題 2 の要件のためのファイルです。このファイルにより、IBM Cloud のコントロール・パネル・ページのパフォーマンスを正確に把握することができます。このファイルは以下の 3 行のフォーマットで構成されています。

Sid,233,ClientBeginRequest,9/6/2011 7:49:14 AM
Sid,285,ClientDoneResponse,9/6/2011 7:49:29 AM
Timepast,14.672

_index.html ファイルと raw ディレクトリーは、Web サイト全体をナビゲーションする間に発行されたすべてのリクエストに対するメトリックを未加工の状態で含んでいます。パフォーマンスに限らず、すべてのメトリックを取得することができます。

Screen_*_.jpg ファイルは各ページのスクリーンショットです。例外に対するトラブルシューティングを行う場合など、シナリオを再現する必要がある場合、この情報が役立ちます。

シナリオ: 機能を制御して基本プログラムを実行する: 帯域幅とシミュレーション

次のシナリオとして、機能を制御して基本プログラムを設定、実行する方法を調べてみましょう。最初に帯域幅の制御とシミュレーションについて説明します。以下のようなコードがあるはずです。

BWEnable=false
BWIN=400Kbit/s
BWOUT=384Kbit/s

ここで BWEnable は帯域幅のシミュレーション、つまり制御のためのスイッチです。BWEnabletrue に設定すると、基本プログラムで帯域幅のシミュレーション機能が有効になります。false に設定するとシミュレーション機能が無効になります。

BWIN パラメーターは TCP/IP でのダウンロード速度を設定するために使われます。

BWOUT パラメーターは TCP/IP でのアップロード速度を設定するために使われます。

シナリオ: 機能を制御して基本プログラムを実行する: キャッシュの制御

機能を制御して基本プログラムを設定、実行する方法のバリエーションとして、キャッシュの制御について調べてみましょう。このシナリオのコードは CacheClean=false のようになります。

ここで、CacheClean はブラウザーのキャッシュを制御するためのフラグです。CacheClean を true に設定すると、基本プログラムの実行前に必ずブラウザーのキャッシュがクリアーされます。CacheClean を false に設定すると、基本プログラムを実行するごとにブラウザーのキャッシュがそのまま保持されます。

シナリオ: 基本プログラムを複数回実行する

最後のシナリオとして、run2run セッションを設定、実行する (基本プログラムを複数回実行する) 方法を見てみましょう。以下のようなコードがあるはずです。

SuccessCapacity=7
TotalExitCapacity=14

基本プログラムを複数回実行することは、基本プログラムを繰り返し実行することと同じです。パフォーマンスを調整する場合、基本的に基本プログラムを複数回実行する必要があります。なぜなら、基本プログラムを 1 回実行するだけではサンプル・データとしては不十分であるため、ユーザーは繰り返し基本プログラムを実行することで、もっと多くのサンプル・データを得ることを望んでいるからです。

そのためには、基本プログラムとは別の Manager.exe というバイナリーを使用する必要があり、そのパラメーターが上記のコードです。SuccessCapacity は、そのバイナリーを起動した状態で基本プログラムの実行が何回成功することを要求しているかを指定する値です。TotalExitCapacity はメイン・ジョブを強制的に終了するための最大値です。累計実行数がこの値を超えると、このバイナリーを起動した状態で実行が何回成功することを要求しているかにかかわらず、メイン・ジョブが強制的に終了されます。

BVT による詳細なメトリックから、何らかの重要なリクエストによってパフォーマンスが低下したかどうかを検出することができます。それを基にコアとなる対策を取ることができ、リクエストのプロファイリング作業を行うことができます。

ページのパフォーマンス・メトリックが正確に得られると、同一条件での傾向を突き止めて、ページ・レベルでパフォーマンスに問題があるかどうかを容易に検出することができます。


まとめ

この記事では、Web アプリケーションの UI のパフォーマンスを調整するために、Fiddler を利用して二次的な開発を行う方法について説明しました。また、その際に生じる 2 つの難題と、その難題に付随する要件について、以下のように詳細に説明しました。

  • 難題 1 を解決するための手段として、対象となる Web リクエストとの完全なやり取りができるように Fiddler を制御、自動化する方法について、一般的なソリューションを説明しました。テスターであれ開発者であれ、この情報を利用することで、少なくとも一連のビルド検証テストを自動化して UI パフォーマンスを監視することができるはずです。またそれにとどまらず、この記事を読むことで重要な機能を習得できたので、Web アプリケーションで測定対象にすべき任意の Web リクエストをコーディングによって特定、制御、検証することもできるようになります。
  • 難題 2 を解決するための手段として、Web アプリケーションのどのページでも必ず必要となる応答パフォーマンスの計算方法について、一般的なソリューションを説明しました。この方法を身に付けると、開始リクエストと終了リクエストをパラメーターとして使用し、この間の時間を計算することで、任意のページの応答パフォーマンスを把握できるようになります。

参考文献

学ぶために

製品や技術を入手するために

  • IBM SmartCloud Enterprise で利用可能な製品イメージを調べてみてください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, Web development
ArticleID=794194
ArticleTitle=IBM SmartCloud Enterprise での UI のパフォーマンスを測定する
publish-date=02232012