(57)【要約】  ユーザ負荷をシミュレートし、ＳＢＣまたはＶＤＩデータセンタインフラストラクチャのパフォーマンスおよび／またはキャパシティを評価するための方法が開示される。方法は、ますます増加する仮想ユーザのために仮想デスクトップインフラストラクチャ上でワークロードを実行する。実行された動作に対するインフラストラクチャの平均レスポンスタイムが所定の閾値を超える際は、その時間の擬似ユーザの数は、インフラストラクチャのキャパシティと考えることができる。【選択図】  図４
2016535890.tif 000002
【特許請求の範囲】
【請求項１】
サーバベースのコンピューティングまたは仮想デスクトップインフラストラクチャのパフォーマンスおよび／またはキャパシティを評価するための方法であって、
ａ）擬似ユーザワークロードで前記インフラストラクチャをロードするステップと、
ｂ）擬似ユーザの数を増加するステップと、
ｃ）ベースラインレスポンスタイムおよび固定レイテンシを含むレスポンスタイムが、前記ステップａ）における前記インフラストラクチャの前記ロードおよび前記ステップｂ）における前記擬似ユーザの数の増加に起因して所定のレスポンスタイム閾値を超える際に、前記インフラストラクチャのキャパシティを決定するステップと
を備える、方法。
【請求項２】
前記ステップａ）が、ユーザワークロードから数テストアプリケーションを開始し、多くのテストアプリケーション内から操作を実行するステップを備える、請求項１に記載の方法。
【請求項３】
多くのテストアプリケーションを開始する前記ステップが、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｏｆｆｉｃｅ、Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ（登録商標）およびＡｄｏｂｅ  ＰＤＦ  Ｒｅａｄｅｒ（登録商標）からなる群からの２つ以上のテストアプリケーションを開始するステップを備える、請求項３に記載の方法。
【請求項４】
前記インフラストラクチャが、前記ステップｄ）が前記インフラストラクチャの前記キャパシティを決定する際に飽和する、請求項１に記載の方法。
【請求項５】
前記インフラストラクチャが、前記ステップｄ）が前記インフラストラクチャの前記キャパシティを決定する際に飽和しない、請求項１に記載の方法。
【請求項６】
前記ベースラインレスポンスタイムが、擬似ユーザワークロードで前記インフラストラクチャをロードする前記ステップａ）の前に実行されるベースラインフェーズにおいて決定される、請求項１に記載の方法。
【請求項７】
前記所定のレスポンスタイム閾値を超える際に、前記ベースラインレスポンスタイムおよび擬似ユーザの数を出力するステップをさらに備える、請求項１に記載の方法。
【請求項８】
前記ステップａ）が、前記インフラストラクチャによってホスティングされるユーザワークロードの数にわたる平均ワークロードを表す中度のワークロードで前記インフラストラクチャをロードするステップを備える、請求項１に記載の方法。
【請求項９】
データセンタにおいてサーバベースのコンピューティングまたは仮想デスクトップインフラストラクチャのパフォーマンスおよび／またはキャパシティを評価するための方法であって、
ａ）低いワークロードの下で前記インフラストラクチャのベースラインレスポンスタイムを決定するためにベースラインフェーズを実行するステップと、
ｂ）擬似ユーザワークロードで前記インフラストラクチャをロードするステップと、
ｃ）擬似ユーザの数を増加するステップと、
ｄ）前記ベースラインレスポンスタイムおよび固定レイテンシを含むレスポンスタイムが、前記ステップａ）における前記インフラストラクチャの前記ロードおよび前記ステップｂ）における前記擬似ユーザの数の増加に起因して所定のレスポンスタイム閾値を超える際に、前記インフラストラクチャのキャパシティを決定するステップと
を備える、方法。
【請求項１０】
前記固定レイテンシが、前記ベースラインレスポンスタイムとは無関係である、請求項９に記載の方法。
【請求項１１】
前記ステップｂ）が、以下の操作、すなわち、
ｅ）ノートパッドアプリケーションを起動する
ｆ）ファイルを開くダイアログを起動する
ｇ）印刷するダイアログを起動する
ｈ）圧縮なしでＰＳＴファイルをＺｉｐ形式にする
ｉ）高圧縮でＰＳＴファイルをＺｉｐ形式にする、および、
ｊ）新しい文書でＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄを起動する
のうちの１つまたは複数を実行するステップを備える、請求項９に記載の方法。
【請求項１２】
ステップｅ）〜ｊ）の前記操作の各々を実行するために要する時間が、互いに関して重み付けされる、請求項１１に記載の方法。
【請求項１３】
データセンタにおいてサーバベースのコンピューティングまたは仮想デスクトップインフラストラクチャのパフォーマンスおよび／またはキャパシティを評価するための方法であって、
ａ）擬似ユーザワークロードで前記インフラストラクチャをロードするステップであって、前記擬似ワークロードが連続セグメントでロードされ、各連続セグメントが、異なる実行時間の長さを要する多くの操作を実行する、ステップと、
ｂ）擬似ユーザの数を増加するステップであって、連続する新しい擬似ユーザの各々が、最初に異なるセグメントを実行し、次いで連続セグメントの実行に進む、ステップと、
ｃ）レスポンスタイムが、前記ステップａ）における前記インフラストラクチャの前記ロードおよび前記ステップｂ）における前記擬似ユーザの数の増加に起因して所定のレスポンスタイム閾値を超える際に、前記インフラストラクチャのキャパシティを決定するステップと
を備える、方法。
【請求項１４】
レスポンスタイムが、ベースラインレスポンスタイムおよび固定レイテンシを含む、請求項１３に記載の方法。
【請求項１５】
前記連続セグメントが、最後のセグメントの後に最初のセグメントにループバックするループで実行される、請求項１３に記載の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
サーバベースのコンピューティング（ＳＢＣ）およびホスト型仮想デスクトップインフラストラクチャ（ＶＤＩ）ソリューションは、データセンタにおいてホスティングされる仮想化されたＷｉｎｄｏｗｓ（登録商標）デスクトップをエンドユーザ（リモートの）に提供するために、今日企業で使用されている。これらの仮想デスクトップは、中央データセンタにおいてホスティングされ、ＬＡＮ、ＷＡＮ、モバイルブロードバンドおよびインターネットなどのネットワーク上でリモートディスプレイプロトコルを通じてリモート操作でユーザによるアクセスが行われる。ＶＤＩおよびＳＢＣデスクトップは、両方とも、データセンタにおいて共有サーバハードウェア上で実行される。仮想マシンモニタまたはハイパーバイザは、データセンタにおいて仮想マシンを作成して実行し、Ｗｉｎｄｏｗｓデスクトップの複数の仮想インスタンスの実行を可能にする。
【０００２】
現在、ＶＤＩ概念はＳＢＣより好まれる場合が多いが、その理由は、各ユーザが、共有および標準化されたＷｉｎｄｏｗｓ（登録商標）サーバデスクトップの代わりに、ユーザ自身の個人のＷｉｎｄｏｗｓデスクトップ上で作業するため、このＶＤＩ概念が最も柔軟性を与えるためである。ＳＢＣでは、複数のデスクトップセッションは、１つのＷｉｎｄｏｗｓ（登録商標）サーバインスタンスから提供される。結果的に、オペレーティングシステムは、ユーザによって共有される。ハイパーバイザなしでＷｉｎｄｏｗｓ（登録商標）サーバをサーバハードウェア上に直接インストールする一方で、ＳＢＣ環境を提供することが可能である。これは、一般に、Ｗｉｎｄｏｗｓサーバのベアメタルインストールと呼ばれる。しかし、Ｗｉｎｄｏｗｓサーバを仮想化し、サーバハードウェア上で仮想化されたＳＢＣ環境を実行することは一般的なことである。
【０００３】
その結果、ＳＢＣとＶＤＩの両方を用いることで、各デスクトップセッションは、ハイパーバイザ、ＣＰＵ、メモリ、ネットワークおよびストレージを含む、データセンタに位置するすべてのサーバハードウェアを共有している。これらのサーバリソースは定義によって制限され、その結果、各ソリューションは特定のキャパシティを有する。ハードウェアとソフトウェアの組合せおよび特定の構成が完全にテストされていない際は、ＳＢＣおよびＶＤＩソリューションのキャパシティがどのようなものになるかを予測することは、不可能ではないにしても難しい。一定数のユーザにデスクトップを提供できるようにするには、どのくらいのハードウェア（サーバ、ネットワークおよびストレージ）が必要かを理解することが最終的に必要であるため、このことはＩＴ組織にとって重要なトピックである。
【０００４】
この決定を下す際の困難の１つは、ＶＤＩまたはＳＢＣ環境の構築が可能な非常に大多数の異なる組合せがあることである。ハードウェアとソフトウェアの両レベルでは、ユーザ経験を改善し、ハードウェアおよびソフトウェアコストを低減するため、技術は継続的に革新される。エンドユーザにとって機能的には同じであるが、根本的な技術は各ソリューションに対して広く異なり、ＶＤＩおよびＳＢＣ市場において新製品を積極的にリリースする多くのベンダが存在する。
【０００５】
革新の多くは、システムのキャパシティへのプラス効果（例えば、ストレージＩＯアクセラレータ）またはシステムのキャパシティへのマイナス効果（例えば、より豊富なエンドユーザ経験のためのマルチメディアサポート）のいずれかを有する。それに加えて、ソフトウェアおよびハードウェアにおける特定の設定は、重大な影響を与え得る。それは、ＶＤＩおよびＳＢＣソリューションのための大量のハードウェアおよびソフトウェアが２つの異なる組織において同一であることであり得る。それでも、Ｗｉｎｄｏｗｓ（登録商標）およびアプリケーションが構成および使用される方法は、各組織において根本的に異なり得る。その結果、２つの組織における２つの表面的に同一のＶＤＩ環境のキャパシティは、実際には、異なるキャパシティを有し得る。
【０００６】
また、ＶＤＩまたはＳＢＣソリューションは、パフォーマンスおよびキャパシティに影響を及ぼす、異なるベンダからの多くの異なるソフトウェアおよびハードウェア要素からなる。これらの例は、仮想デスクトップブローカソフトウェア、ハイパーバイザ、セキュリティソフトウェア、オフィスおよびビジネスアプリケーション、サーバハードウェア、（共有）ストレージならびにネットワーク（ＬＡＮとＷＡＮの両方）がある。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
実際のユーザが展開された仮想デスクトップ環境で作業する前に、データセンタにおける個々のサーバおよび完全な環境のキャパシティがどのようなものかを予測できることが有利であろう。
【課題を解決するための手段】
【０００８】
本技術の実施形態は、大まかに説明すると、ユーザ負荷をシミュレートし、ＳＢＣまたはＶＤＩソリューションのパフォーマンスおよび／またはキャパシティを評価するためのシステムおよび方法に関連する。本技術は、ますます増加する仮想ユーザのために仮想デスクトップインフラストラクチャ上でワークロードを開始して実行する。実行された動作に対するインフラストラクチャの平均レスポンスタイムが所定の閾値を超える際は、その時間の擬似ユーザの数は、インフラストラクチャのキャパシティと考えることができ、本明細書ではＶＳＩＭａｘと呼ばれる。
【０００９】
ＶＳＩアプリケーションは、組織が、彼ら自身の環境において、異なるソフトウェアおよびハードウェアソリューションのパフォーマンスをテストおよび比較できるようにする。ＶＳＩアプリケーションは、所望の数のユーザおよびアプリケーションをサポートするために最適なハードウェア構成（ライトサイジング）を決定する上で役立つ。当て推量に基づくのではなく、客観的データに基づく。
【００１０】
ＶＳＩアプリケーションは、ＶＳＩＭａｘインデックスを計算する。異なる実施形態における様々な計算は、ＶＳＩＭａｘ  Ｃｌａｓｓｉｃ、ＶＳＩＭａｘ  ＤｙｎａｍｉｃおよびＶＳＩＭａｘ  ｖ４を生み出す。ＶＳＩＭａｘ  ｖ４などのインデックスを使用することで、ユーザは、現在の生産インフラストラクチャの最大キャパシティを決定することができる。擬似ユーザは、Ｗｏｒｄ、Ｅｘｃｅｌ、ＯｕｔｌｏｏｋおよびＩｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒなど、平均的な従業員と同じアプリケーションで作業する。必要な場合は、カスタムアプリケーションをテストに追加することが可能である。ＶＳＩアプリケーションは、さらに、組織が、ＶＤＩまたはＳＢＣインフラストラクチャのパフォーマンスへのソフトウェアおよびハードウェアにおけるいかなる変更の影響もテストおよび予測できるようにする。
【００１１】
本技術は、ハードウェア、ソフトウェア、または、ハードウェアとソフトウェアの組合せを使用して実現することができる。本発明のために使用されるソフトウェアは、ハードディスクドライブ、ＣＤ−ＲＯＭ、ＤＶＤ、光ディスク、フロッピー（登録商標）ディスク、テープドライブ、ＲＡＭ、ＲＯＭまたは他の適切な記憶装置を含む１つまたは複数のプロセッサ可読記憶媒体上に格納される。代替の実施形態では、ソフトウェアのいくつかまたはすべては、カスタム集積回路、ゲートアレイ、ＦＰＧＡ、ＰＬＤおよび特殊用途コンピュータを含む専用ハードウェアに置き換えることができる。一実施形態では、本発明を実装するソフトウェアは、１つまたは複数のプロセッサをプログラムするために使用される。プロセッサは、１つまたは複数の記憶装置、周辺機器および／または通信インタフェースと連通することができる。
【００１２】
一例では、本技術は、サーバベースのコンピューティングまたは仮想デスクトップインフラストラクチャのパフォーマンスおよび／またはキャパシティを評価するための方法であって、ａ）擬似ユーザワークロードでインフラストラクチャをロードするステップと、ｂ）擬似ユーザの数を増加するステップと、ｃ）ベースラインレスポンスタイムおよび固定レイテンシを含むレスポンスタイムが前記ステップａ）におけるインフラストラクチャのロードおよび前記ステップｂ）における擬似ユーザの数の増加に起因して所定のレスポンスタイム閾値を超える際にインフラストラクチャのキャパシティを決定するステップとを含む、方法に関する。
【００１３】
別の例では、本技術は、データセンタにおいてサーバベースのコンピューティングまたは仮想デスクトップインフラストラクチャのパフォーマンスおよび／またはキャパシティを評価するための方法であって、ａ）低いワークロードの下でインフラストラクチャのベースラインレスポンスタイムを決定するためにベースラインフェーズを実行するステップと、ｂ）擬似ユーザワークロードでインフラストラクチャをロードするステップと、ｃ）擬似ユーザの数を増加するステップと、ｄ）ベースラインレスポンスタイムおよび固定レイテンシを含むレスポンスタイムが前記ステップａ）におけるインフラストラクチャのロードおよび前記ステップｂ）における擬似ユーザの数の増加に起因して所定のレスポンスタイム閾値を超える際にインフラストラクチャのキャパシティを決定するステップとを含む、方法に関する。
【００１４】
さらなる例では、本技術は、データセンタにおいてサーバベースのコンピューティングまたは仮想デスクトップインフラストラクチャのパフォーマンスおよび／またはキャパシティを評価するための方法であって、ａ）擬似ユーザワークロードでインフラストラクチャをロードするステップであって、擬似ワークロードが連続セグメントでロードされ、各連続セグメントが、異なる実行時間の長さを要する多くの操作を実行する、ステップと、ｂ）擬似ユーザの数を増加するステップであって、連続する新しい擬似ユーザの各々が、最初に異なるセグメントを実行し、次いで連続セグメントの実行に進む、ステップと、ｃ）レスポンスタイムが前記ステップａ）におけるインフラストラクチャのロードおよび前記ステップｂ）における擬似ユーザの数の増加に起因して所定のレスポンスタイム閾値を超える際にインフラストラクチャのキャパシティを決定するステップとを含む、方法に関する。
【００１５】
この概要は、以下の詳細な説明でさらに説明される簡素化された形態での概念の選択を紹介するために提供される。この概要は、特許請求される対象物の主要な特徴または本質的な特徴を特定することを意図せず、特許請求される対象物の範囲の決定の補助として使用することを意図しない。
【図面の簡単な説明】
【００１６】
【図１】本技術を実装できるネットワークアーキテクチャのブロック図である。
【図２−３】経時的なユーザ負荷を示すグラフである。
【図３−８】本技術の実施形態の動作を示すフローチャートである。
【図９】本システムの実装が可能なコンピューティングシステム環境のブロック図である。
【発明を実施するための形態】
【００１７】
ここでは、図に関して本技術を説明し、一般に、ユーザ負荷をシミュレートし、ＳＢＣまたはＶＤＩソリューションのパフォーマンスおよび／またはキャパシティを評価するためのシステムおよび方法に関する。本発明は、多くの異なる形態で具体化することができ、本明細書に記載される実施形態に限定されると解釈すべきではないことが理解されている。むしろ、この開示が、徹底的なおよび完全なものになり、当業者に本発明を十分に伝えるように、これらの実施形態は提供される。まさに、本発明は、これらの実施形態の代替形態、変更形態および均等物を包含することが意図され、これらは、添付の請求項によって定義されるように、本発明の範囲および精神内に含まれる。その上、本発明の以下の詳細な説明では、多くの具体的な詳細は、本発明の徹底的な理解を提供するために記載される。しかし、当業者であれば、そのような具体的な詳細なしで本発明を実践できることが明確であろう。
【００１８】
図１を参照すると、本技術を実装できるネットワークアーキテクチャ１００の高レベルのブロック図が示されている。一構成では、アーキテクチャは、データセンタにおいてホスティングされる仮想化されたＷｉｎｄｏｗｓデスクトップ（例えば、ＶＤＩまたはＳＢＣ）をエンドユーザに提供する対象プラットフォーム１０２を含み得る。これらの仮想デスクトップは、中央データセンタにおいてホスティングされ、ＬＡＮ、ＷＡＮ、モバイルブロードバンドおよびインターネットなどのネットワーク１０４上でリモートディスプレイプロトコルを通じてリモート操作でユーザによるアクセスが行われる。ＶＤＩおよびＳＢＣデスクトップは、両方とも、データセンタにおいて共有サーバハードウェア上で実行される。ハイパーバイザは、データセンタにおいて仮想マシンを作成して実行し、Ｗｉｎｄｏｗｓデスクトップの複数の仮想インスタンスの実行を可能にする。
【００１９】
アーキテクチャ１００は、ネットワーク１０４を介して対象プラットフォーム１０２に接続されたランチャワークステーション１０６をさらに含み得る。ランチャワークステーションは、Ｌｏｇｉｎ  ＶＳＩセッションがそこから着手および開始されるＷｉｎｄｏｗｓデスクトップインスタンスであり得る。通常、ランチャは、仮想デスクトップとして実行されるが、物理的なＷｉｎｄｏｗｓ（登録商標）マシンもまたサポートされる。２０〜５０のＬｏｇｉｎ  ＶＳＩセッションに対して構成された少なくとも１つのランチャワークステーションが存在し得る。これは、使用されるワークロードおよびプロトコルに依存し、さらなる実施形態で異なり得る。実施形態では、本技術の態様による仮想セッションインデクサ（ＶＳＩ）ソフトウェアアプリケーション１１２のインスタンスは、ランチャワークステーション１０６に存在し得る。ワークステーション１０６は、以下で説明されるように対象プラットフォームをロードするためにリモートセッションに自動的に着手するために、ＶＳＩアプリケーションを実行することができる。
【００２０】
アーキテクチャ１００は、テストユーザアカウントおよび標準ポリシのためのアクティブディレクトリ（ＡＤ）コントローラ１０８をさらに含み得る。コントローラ１０８は、テストユーザアカウントを作成することができ、グループポリシオブジェクト（ＧＰＯ）をインポートしてリンクすることができる。ＡＤドメインコントローラ１０８は、Ｗｉｎｄｏｗｓ（登録商標）ドメインタイプネットワークのすべての（ＶＳＩテスト）ユーザおよび仮想デスクトップコンピュータを認証および許可し、すべてのＶＳＩユーザおよびコンピュータのためのセキュリティポリシの割り当ておよび実施を行う。
【００２１】
ファイル共有サーバ１１０は、中央構成のためにアーキテクチャ１００にさらに含めることができ、ＶＳＩアプリケーションによって生成されたデータを格納することができる。ファイルサーバは、Ｌｏｇｉｎ  ＶＳＩランタイムおよび構成ファイル、共有されたＬｏｇｉｎ  ＶＳＩ文書およびメディアライブラリの中央格納のための場所を提供するという主要な目的を有するＷｉｎｄｏｗｓサーバであり、テストから得られたＬｏｇｉｎ  ＶＳＩ結果が格納される主要な場所の機能を果たす。
【００２２】
一般に、ＶＳＩアプリケーションは、対象プラットフォーム上のユーザワークロードをシミュレートするスクリプトの実行を制御し、スクリプトを実行するための対象プラットフォームのパフォーマンスおよびキャパシティを評価する。ＶＳＩアプリケーションは、システム飽和を通じてＳＢＣまたはＶＤＩワークロードに対するベンチマークを実行する。ＶＳＩアプリケーションは、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｏｆｆｉｃｅ、Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ（登録商標）およびＡｄｏｂｅ  ＰＤＦ  Ｒｅａｄｅｒ（登録商標）のような周知のデスクトップアプリケーションを使用して、擬似ユーザワークロードをシステムにロードする。擬似ユーザの数を徐々に増加することによって、システムは、最終的に飽和するようになる。システムが飽和した時点で、アプリケーションのレスポンスタイムはかなり増加し得る。このアプリケーションレスポンスタイムにおけるレイテンシは、システムが過負荷を受けているかまたは過負荷を受けている状態に近いかに関するインジケータとして使用される。従って、ＶＳＩアプリケーションは、今にもシステムに過負荷をかけそうになり、そうなることによって、システムに対する真の最大ユーザキャパシティがどのようなものかに関する情報を提供する。
【００２３】
ＶＳＩＭａｘ
ＶＳＩアプリケーションは、ＶＳＩＭａｘ値（本明細書では、単にＶＳＩＭａｘとも呼ばれる）を出力する。ＶＳＩＭａｘは、最大アクティブセッション／デスクトップキャパシティの測定単位またはインデックスである。このインデックスは、比較を簡素化し、ハイパーバイザホストまたはゲストレベルでの構成変更の真の影響を理解することを可能にする。
【００２４】
サーバ側のレスポンスタイムの測定
リモートセッションを使用する代わりに、セッション内において対象システム上で直接ワークロードを実行するために、ＶＳＩアプリケーションにおける設計選択が行われた。ワークロードをシミュレートするテストアプリケーションまたはスクリプトは、対象システム上でコンパイル済みのＡｕｔｏＩＴスクリプトとして実行され、擬似ユーザのデスクトップセッションのコンテキスト内においてログオン時に着手される。
【００２５】
代替の実施形態では、ユーザ操作は、リモートプロトコルを通じてクライアント側で生成することができる。Ｍｉｃｒｏｓｏｆｔ  ＲＤＰおよびＣｉｔｒｉｘ  ＩＣＡ／ＨＤＸのようなリモートプロトコルは、これをサポートする。これらの方法は、製品に特有であり、ベンダに依存している。プロトコルレベルでの変更に伴ってまたは新しいリモートソリューションに伴って、ＶＳＩアプリケーションを修正／拡大してこれらの変更をサポートする必要があり得る。
【００２６】
しかし、ほとんどの例では、ＡｕｔｏＩＴを用いて完全にサーバ側でスクリプトを実行するように選択が行われてきた。これは、プラットフォームに依存しないソリューションである。ＡｕｔｏＩＴの相対的なオーバーヘッドおよびフットプリントは、ＶＳＩアプリケーションの目的に対して十分に小さい（１〜５％の範囲）。
【００２７】
ＶＳＩＭａｘの計算
以下で説明されるように、ＶＳＩアプリケーションは、擬似ユーザの数に対する擬似ワークロードでＳＢＣまたはＶＤＩインフラストラクチャをロードし、ユーザの数は、経時的に増加される。ＶＳＩＭａｘは、所定のレスポンスタイム閾値に達するかまたはそれを超える際の、ＳＢＣまたはＶＤＩインフラストラクチャ上で擬似ワークロードを実行している擬似ユーザの数の測定単位であり得る。実施形態では、擬似デスクトップワークロードは、擬似ＶＳＩユーザがログオンし、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｏｆｆｉｃｅなどの開かれているテストアプリケーション内の一般的な活動を実行する際に、４８分ループでスクリプト化される。ループが終了した後は、ループを自動的に再スタートすることができる。各ループ内では、６つの特定の動作のレスポンスタイムが一定の間隔で（各ループ内で１２回）測定される。特定の動作の数は６つより多くとも少なくともよく、動作の回数は一定の間隔で測定され、１２回より多くとも少なくともよいことが理解されている。これらの６つの動作のレスポンスタイムは、ＶＳＩＭａｘを決定するために使用される。
【００２８】
レスポンスタイムが測定される６つの動作は以下の通りであり得る。
【００２９】
「ＶＳＩノートパッド」を起動する
この動作は、ＯＳによって（ＶＳＩａｐｐｌｉｃａｔｉｏｎＮｏｔｅｐａｄ．ｅｘｅをロードし、着手する）およびＶＳＩＮｏｔｅｐａｄ．ｅｘｅ自体によって実行を通じて処理される。この動作は、エンドユーザの視点からはほとんど瞬時であるように見える。
【００３０】
「ファイルを開く」ダイアログを起動する
この動作は、開かれたテストアプリケーション（Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄなど）によって部分的におよびオペレーティングシステムによって部分的に処理される。ファイルを開くダイアログは、ＯＳの一般的なサブシステムおよびインタフェースコンポーネントを使用する。ＯＳは、このダイアログのコンテンツを提供する。
【００３１】
「印刷する」ダイアログを起動する
この動作は、印刷するダイアログがＯＳによって提供されるため、ＯＳサブシステムによって部分的に処理される。このダイアログは、選択されたプリンタの印刷サブシステムおよびドライバをロードする。その結果、このダイアログもまた、ディスクパフォーマンスに依存する。
【００３２】
７−ｚｉｐコマンドラインで文書をｚｉｐファイルに圧縮する（２ｘ）
この動作は、７−ｚｉｐのコマンドラインバージョン（または他のファイル圧縮アルゴリズム）によって処理される。圧縮は、ＣＰＵおよびディスクＩＯを一時的に急上昇させる。この動作は、２回実行することができる（圧縮なしで１回（ＩＯ集約型）および高圧縮で１回（ＣＰＵ集約型））。
【００３３】
文書でＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄを起動する
この動作は、オペレーティングシステムおよびファイルシステムの応答性を測定する。Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄが起動され、メモリにロードされ、また、新しい文書がＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄに自動的にロードされる。ディスクＩＯが大量であるかまたはましてや飽和している際には、これは、ファイルを開くダイアログにかなり影響を与える。ここでのＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄの使用は単なる例示であり、他のテストアプリケーションを使用できることが理解されている。
【００３４】
ＶＳＩアプリケーションでのこれらの測定動作は、ＣＰＵ（ユーザおよびカーネル）、メモリ、ディスク、一般的なＯＳ、アプリケーション自体、印刷、ＧＤＩなどの異なるサブシステムにかなり影響を与える。これらの動作は、厳密に言えば、もともと短い。そのような動作が一貫して長くなると、任意の種類のリソースの過剰なキューイングのためにシステムが飽和する。その結果、平均レスポンスタイムが段階的に増大する。この効果は、エンドユーザにはっきりと見える。そのような動作が一貫して複数秒かかる場合は、ユーザは、システムを、遅くて応答がないものと見なす。
【００３５】
図２のチャートは、Ｌｏｇｉｎ  ＶＳＩで実行されたテストの例示的なＶＳＩアナライザの結果グラフを示す。この例示的なテストは、深刻なパフォーマンス問題なしで実行された。垂直軸は、ミリ秒単位でのＶＳＩレスポンスタイムを示し、水平線は、システム上でアクティブなＶＳＩユーザの数を表示する。緑色の線は、最も低いＶＳＩレスポンスタイムを示す。赤色の線は、最も高いＶＳＩレスポンスタイムを示す。黄色の線は、平均レスポンスタイムを示す。青色の線は、計算されたＶＳＩＭａｘレスポンスタイムを示す。この例では、最大９０のセッションまでの平均ＶＳＩレスポンスタイムは極度のレイテンシを呈さないことが明確である。約９５のセッション後には、レスポンスタイムはかなり増加する。ＶＳＩＭａｘは、ＶＳＩアプリケーションによって９２のセッションで計算される。
【００３６】
図３のチャートは、図２で言及されるものと同様のＶＳＩテストの例示的な結果を示し、デスクトップ内でアンチウイルスエージェントがインストールされる。これはデフォルトのアンチウイルスエージェントインストールであるため、かなりのパフォーマンスオーバーヘッドを有し、すべてのアプリケーションのレスポンスタイムへのマイナス影響を有する。現実世界のユーザは、このシステムを、遅過ぎて生産性が高くないものと見なすであろう。ＶＳＩアプリケーションは、この例では、ＶＳＩＭａｘを計算することができない可能性がある。
【００３７】
ＶＳＩアプリケーションにより、ユーザは、異なるＶＳＩＭａｘインデックス（「ＶＳＩＭａｘ  Ｃｌａｓｓｉｃ」、「ＶＳＩＭａｘ  Ｄｙｎａｍｉｃ」および「ＶＳＩＭａｘ  ｖ４」）間で選ぶことができる。ＶＳＩＭａｘ  ＣｌａｓｓｉｃおよびＶＳＩＭａｘ  Ｄｙｎａｍｉｃは、より小さなシステムに適しており、ＶＳＩＭａｘ  ｖ４は、システムパフォーマンスにおいてより良い見識を与え、極めて大きなシステムまで拡大する。
【００３８】
ＶＳＩＭａｘ  Ｃｌａｓｓｉｃ
ＶＳＩＭａｘ  Ｃｌａｓｓｉｃは、平均ＶＳＩレスポンスタイムが４０００ｍｓの固定閾値より高い際に達成される。この方法は、アンチウイルスまたはアプリケーション仮想化が使用されない際は信頼できることが判明している。レスポンスタイムを計算するため、７つの活動が総計される（ＶＳＩＭａｘ  Ｖ４は６つの動作を使用することができ、ＶＳＩＭａｘ  Ｃｌａｓｓｉｃは７つの動作を使用することができる）。これらのバランスを取るため、測定は、合計する前に重み付けされる。ＶＳＩＭａｘ  Ｃｌａｓｓｉｃ内では、総ＶＳＩＭａｘレスポンスタイムに加える前に２つの測定を重み付けすることができる。例えば、テストアプリケーションがＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄである場合、
・「文書でＭｉｃｒｏｓｏｆｔ  Ｗｏｒｄを起動する」を２で除することができる（すなわち、５０％で重み付けされる）。
・「「検索するおよび置き換える」ダイアログを起動する」に５を乗ずることができる（すなわち、５００％で重み付けされる）。
【００３９】
ＶＳＩＭａｘ  Ｃｌａｓｓｉｃレスポンスタイム計算のサンプルは、以下の表１に表示される。
【００４０】
【表１】
2016535890.tif 000003
【００４１】
次いで、システムにログオンしたアクティブユーザの数に基づいて、平均ＶＳＩＭａｘレスポンスタイムを計算することができる。平均ＶＳＩＭａｘレスポンスタイムが４０００ｍｓのデフォルト閾値より一貫して高い際に、ＶＳＩＭａｘが達成される。閾値は、さらなる実施形態では、４０００ｍｓを上回っても下回ってもよいことが理解されている。
【００４２】
実際には、テストは、アンチウイルスおよび／またはアプリケーション仮想化が使用される際は、アプリケーションレスポンスタイムの実質的な増加を示している。ベースラインレスポンスタイムは、通常、アプリケーション仮想化またはアンチウイルスなしで約１４００〜１８００ｍｓである。しかし、アンチウイルスまたはアプリケーション仮想化が使用されると、ベースラインレスポンスタイムは、２５００〜３５００ｍｓで異なり得る。ベースラインレスポンスタイムが既に高過ぎる際は、４０００ｍｓのＶＳＩＭａｘ  Ｃｌａｓｓｉｃ閾値には、あまりにも容易に達することができる。「ＶＳＩＭａｘ  Ｃｌａｓｓｉｃ」は、ＣＰＵ、ＲＡＭまたはディスクのようなシステムリソースが実際に飽和する前に、最長時間を報告する。この問題は、ＶＳＩＭａｘ  Ｄｙｎａｍｉｃインデックスで対処される。
【００４３】
ＶＳＩＭａｘ  Ｄｙｎａｍｉｃ
ＶＳＩＭａｘ  Ｃｌａｓｓｉｃと同様に、ＶＳＩＭａｘ  Ｄｙｎａｍｉｃは、レスポンスタイムが一貫して一定の閾値を上回る際に計算される。しかし、この閾値は、ここでは、テストのベースラインレスポンスタイムに基づいて動的に計算される。一例では、この手法をより良くサポートするために、５つの個々の測定が重み付けされる。以下は、測定および重みをリストする。提供される重みは、単なる例示であり、リストされる値を上回ってまたは下回って異なり得る。その上、リストされるものに加えてまたはその代わりに、測定を使用することができる。
・ホームドライブの文書プールから新しい文書をコピーする：１００％
・文書でＭｉｃｒｏｓｏｆｔ  Ｗｏｒｄ：３３．３％
・「ファイルを開く」ダイアログを起動する：１００％
・「ノートパッド」を起動する：３００％
・「印刷する」ダイアログを起動する：２００％
・「検索するおよび置き換える」ダイアログを起動する：４００％
・７−ｚｉｐコマンドラインで文書をｚｉｐファイルに圧縮する：２００％
【００４４】
ＶＳＩＭａｘ  Ｄｙｎａｍｉｃレスポンスタイム計算のサンプルは、以下の表２に表示される。
【００４５】
【表２】
2016535890.tif 000004
【００４６】
次いで、システムにログオンしたアクティブユーザの数に基づいて、平均ＶＳＩＭａｘレスポンスタイムが計算される。これに対し、平均ＶＳＩＭａｘレスポンスタイムは、動的に計算された閾値より一貫して高い必要がある。この動的閾値を決定するため、最初に、平均ベースラインレスポンスタイムが計算される。この計算は、システム上の最初の１５人のユーザのベースラインレスポンスタイムを平均することによって行われる。
【００４７】
動的閾値の式は、以下の通りである。
平均ベースラインレスポンスタイム×１２５％＋３０００ｍｓ
その結果、ベースラインレスポンスタイムが１８００である際は、ＶＳＩＭａｘ閾値は、ここでは、１８００×１２５％＋３０００＝５２５０ｍｓである。１２５％の乗数は、さらなる例では、その数を上回っておよび下回って異なり得、３０００ｍｓの定数は、さらなる例では、その数を上回っておよび下回って異なり得る。ベースラインレスポンスタイムは、特にアプリケーション仮想化が使用される際は、ベンダおよびストリーミングストラテジごとに異なり得る。
【００４８】
ＶＳＩＭａｘ  ｖ４
ＶＳＩアプリケーションは、ＶＳＩＭａｘ  ｖ４インデックスを計算するオプションをさらに提供する。ＶＳＩＭａｘ  ｖ４を計算するためのＶＳＩアプリケーションは、本明細書では、上記の通りＶＳＩアプリケーションまたは「ＶＳＩアプリケーションｖ４」と呼ばれる。例えば、４８分の増加されたループ長を使用することができる。ＶＳＩＭａｘ  Ｃｌａｓｓｉｃおよび／またはＤｙｎａｍｉｃでは、ループ長は、例えば、１４分であり得る。１４分で、動作が実行されたが、それは圧縮方法によるものである。４８分のループ長を使用することで、ユーザ活動をより厳密にエミュレートし、アプリケーション起動の量をより現実的な割合まで減少する。
【００４９】
中度のワークロードを１２分の４つの部分にセグメント化し、新しいテストユーザの各々に対するセグメント開始を交互に行うことにより、４８分のワークロードループは、依然として、ベンチマーキングに適している。これにより、最初のユーザから最後のユーザまで、異なる活動によってシステムがロードされることが保証される。例えば、ワークロードのセグメント化なしでは、ある一定のよりリソース集約型の部分（マルチメディアのような）は、テストの終了時に起こり得、それは、一連の限定されたユーザに対してのみ起こり得る。セグメント開始が新しいユーザの各々に対して交互に行われると、ワークロードにおけるすべての活動は、テストの開始時から使用される。
【００５０】
ワークロードのリアリズムをさらに増大させるため、データはＷｉｎｄｏｗｓの画像内には格納されず、別個のデータサーバ上に格納される。ＶＳＩアプリケーションｖ４の全データセットは、２０ＧＢであり得（他の実施形態では、データセットはより小さいものであり得、例えば、３００ＭＢである）、各タイプの１０００のオフィス文書のデータセットを伴う。また、文書サイズは、この実施形態では、かなり大きいものであり得、今日見られる文書の典型である。
【００５１】
すべてのセッションの開始ウィンドウは、ＶＳＩＭａｘ  ｖ４が計算される際は、４８分に固定することができる。これにより、テストユーザのログオンレートがユーザの総数に依存するようになる。固定された開始ウィンドウは、１００人のユーザ、１００，０００人のユーザおよびその間の任意の数のユーザでのＶＳＩアプリケーションｖ４でのシステムのテストを可能にする。この範囲は、単なる例示であり、ＶＳＩアプリケーションｖ４を使用して、より多くのまたはより少ない数のユーザをテストすることができる。
【００５２】
ＶＳＩアプリケーションの他の実施形態では、ベースラインレスポンスタイム測定は、テストを実際に開始する間に実行された。これは、ベースラインパフォーマンスに容易に影響を及ぼし得るが、その理由は、ワークロード自体が、既に、システムリソースへのかなりの影響を有しており、結果的に、ベースライン測定値に影響を及ぼすためである。これに対処するため、ＶＳＩアプリケーションｖ４は、ベースラインフェーズを導入している。最初に、ワークロードが実行される前にシステム上で５人のテストユーザをロードし、他の活動がない間にシステムのＶＳＩレスポンスタイムのみを測定することによって、ベースラインパフォーマンスは、一貫し、ワークロードによる影響を受けない。
【００５３】
ＶＳＩアプリケーションｖ４レスポンスタイムを測定するための重み付けおよび操作は、システムパフォーマンスをより良く表現するように変更されている。他の実施形態では、例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄのアプリケーション起動は、総レスポンスタイムを支配した。ＶＳＩアプリケーションｖ４では、測定は、等しい重みを有する。これにより、すべてのレベル（ＣＰＵ、メモリ、ディスクＩＯ、アプリケーションおよびＯＳレベル）でのパフォーマンス問題が浮き彫りにされる。
【００５４】
ＶＳＩアプリケーションｖ４によるＶＳＩＭａｘ  ｖ４の計算は、ＶＳＩＭａｘ  ＣｌａｓｓｉｃおよびＶＳＩＭａｘ  Ｄｙｎａｍｉｃの計算とは異なる。ここでは、レスポンスタイムレイテンシ閾値（重み付けされた）は固定される。ＶＳＩアプリケーションｖ４の重点は、レスポンスタイムレイテンシにあり、他の実施形態にあるような総レスポンスタイムにはない。ここでは、アンチウイルス、セキュリティ、アプリケーション仮想化または他のプラグインなどを実行しているソフトウェア（インフラストラクチャ）とは無関係に、異なるシステムを徹底的に比較することが可能である。
【００５５】
ＶＳＩアプリケーションｖ４は、ベースラインレスポンスタイムと共にセッション密度について報告する。ベースラインパフォーマンスは、個々のユーザがどのような最高のパフォーマンスを予期できるかを示す。これは、セッション密度とは無関係である。高速デュアルコアシステムは、より低速の１０コアＣＰＵを有するシステムより良いパフォーマンスを個々のユーザに容易に与える。しかし、１０コアＣＰＵシステムは、はるかに大きなユーザキャパシティを容易に有するであろう。ＶＳＩＭａｘ  ｖ４（高い方がよい）とベースラインレスポンスタイムパフォーマンス（低い方がよい）の両方を報告することによって、システム能力のはるかに良い理解が得られる。
【００５６】
ＶＳＩアプリケーションｖ４の概要
以下の図は、ＶＳＩアプリケーションｖ４テストの機構を表す。これらは一般に下記事項からなる。
・接続設定およびランチャを事前構成する
・ベースラインレスポンスタイム測定を開始する
・ＶＳＩアプリケーションテストを開始する
・中度のワークロードを実行する
・セグメントを開始する
【００５７】
準備フェーズ
ここで、図４のフローチャートを参照すると、準備フェーズでは、テスト対象システムのテスト準備が行われる。テスト済みのデスクトップのプールが事前に立ち上げられる。すべてのデスクトップ仮想マシン（ＶＤＩ）またはサーバ仮想マシン（ＳＢＣ）が起動され、ＶＳＩアプリケーションテストユーザセッションを受信する準備が整えられる。
【００５８】
ステップ４００：接続設定およびランチャを事前構成する
ＶＳＩアプリケーションは、ユニバーサル接続構成ウィザードを通じて、いかなるＶＤＩおよびＳＢＣソリューションもサポートする。ランチャ上でセッションに自動的に着手するため、コマンドラインインタフェースを通じてクライアントソフトウェアを動作する必要があり、これは、ＶＳＩアプリケーション管理コンソールで構成される。
【００５９】
ステップ４０２：ＶＳＩアプリケーションコンソールでベンチマーキングモードを可能にする
これは、構成オプションを制限し、４８分の開始ウィンドウおよび中度のワークロードを強制する。このＶＳＩアプリケーションｖ４ルーチンは、現在のおよび将来のハードウェアの生成や、サーバサイジングとファームサイジングの両方に適している。セッションは、特定の時間枠（例えば、４８分）内に開始される。この時間枠は、ほとんどの組織での忙しい朝に典型的なログオンレートに等しく、４８分は、ユーザシミュレーションループの全体の長さである。最初のユーザは、テストの終了までに全ワークロードを完了するであろう。これらのセッションの開始は、等しく時間分布することができる（ただし、さらなる実施形態では、そうする必要はない）。開始間隔は、以下の通りであり得る。
２８８０秒（４８分）／開始された全セッション＝１セッションあたりの開始間隔
【００６０】
このセッション開始計画には、ＶＳＩアプリケーションの他の実施形態やホスティングされたデスクトップ仮想化のための従来のベンチマークアプリケーションと比較すると、２〜３の利点がある。ＶＳＩアプリケーションの他の実施形態では、ＶＳＩＭａｘは、３０秒ごとに１つのセッションを開始することによって確立された。しかし、サーバハードウェアキャパシティは、特にプロセッサおよびメモリの観点から、継続的に改善している。その結果、ログオンプロセスからの相対負荷（ワークロードの重要な部分であり、かなりのリソースを消費する）は、サーバがより多くのプロセッサコアを有するＣＰＵで構成されると、減少する。個々のプロセッサ上の相対負荷は、１つのＣＰＵあたり４つのコアを有するサーバよりも、１つのＣＰＵあたり１０のコアを有するサーバ上でかなり低い。
【００６１】
また、１ユーザセッションあたり３０秒の固定間隔は、大規模テストでは実用的ではない。例えば、２０１０年には、当時の典型的なサーバハードウェア上で約１００のデスクトップセッションをホスティングすることは当たり前であった。現在は、１つのサーバあたり２００に近い。テストの時間は、現代のシステムのキャパシティの増加のため、２倍になる。この傾向は、断固として続き、将来、停止しそうにない。従って、例えば、２０１５年には、３００〜４００のＶＳＩアプリケーションセッションが標準であることが予期され得る。
【００６２】
特に、大規模な環境のテストでは、各セッション間に３０秒の開始間隔を有することは実用的ではない。例えば、１０００のセッションが開始されると、３０，０００秒要することになり、テスト遂行に８時間超を要する。
【００６３】
ＶＳＩアプリケーションｖ４において、固定された開始ウィンドウを実装することによって、いかなる仮想デスクトップ環境（単一のサーバから非常に大きな環境まで）も、完全にテストすることができる。固定間隔のため、相対ログオンレートは、キャパシティがかなり大きい時でさえ、等しいままである。
【００６４】
ステップ４０４：開始すべきセッションの数を設定する
テストに対し、開始するように構成されたセッションの数は、利用可能なデスクトップ仮想マシンと同じである。ＶＤＩがテストされる際は、デスクトップ仮想マシンより多くのセッションを構成することは、技術的に可能ではない。すなわち、あらゆる仮想マシンは、１つのセッションしか実行できないのである。セッションによってロードされなかった仮想マシンがリソースを消費するため（ただし、テストの一部ではない）、デスクトッププールにおいて利用可能な仮想マシンより少ないセッションを構成することは好ましくない。
【００６５】
ステップ４０６：テストに名を付けて開始する
ＶＳＩアプリケーションコンソールは、テストの名前および説明を要求する。
【００６６】
ステップ４０８：すべてのランチャの準備が整うのを待つ
テストが開始される前に、すべてのランチャマシンの準備を整え、テスト開始を待つ必要がある。すべてのランチャの準備が整うと、システムのベースラインパフォーマンスを測定することができる。
【００６７】
準備フェーズは、ステップ４１０で終了する。
【００６８】
ＶＳＩアプリケーションｖ４ベースラインレスポンスタイム測定
ステップ５００：ベースラインレスポンスタイム測定を開始する
ここで、図５のフローチャートを参照すると、それは、システムのベースラインパフォーマンスを測定するためのＶＳＩアプリケーションｖ４の特徴である。これにより、ＶＳＩアプリケーションｖ４は、負荷の下でのレスポンスタイムのレイテンシを測定することができる。システムのベースラインパフォーマンスは、システムがエンドユーザに提供できる最高のレスポンスである。これは、ＶＳＩアプリケーションｖ４で通常のワークロードを実行することなく測定される。このフェーズの間は、ＶＳＩレスポンスタイムのみが測定され、他の活動がシステム上で起こることはない。
【００６９】
ＶＳＩアプリケーションの他の実施形態により、ベースラインレスポンスタイムは、ワークロードが実行されている間に測定される。ワークロードがリソース集約型であるため、ベースラインパフォーマンスは容易に影響を受ける可能性がある。ＶＳＩアプリケーションｖ４における実際のテスト開始前にベースラインパフォーマンスを別々に測定することによって、結果は、最適なものとなり、ワークロード自体による影響を受けない。
【００７０】
ステップ５０２：最初の５人のＶＳＩアプリケーションユーザのログオンを行う
ベースラインパフォーマンスを測定するため、最初の５人の常連のＶＳＩアプリケーションテストユーザ（すなわち、擬似ユーザ）は、システムにログオンする。
【００７１】
ステップ５０４：９０秒待つ
各ユーザは、ＶＳＩレスポンスタイムの測定前に９０秒待つ。これにより、システムは、「静止」し、背景で起こっているログオンプロセスを終了することができる。さらなる実施形態では、９０秒より長いまたは短い時間を使用できることが理解されている。
【００７２】
ステップ５０６：５つのレスポンスタイム測定を３０秒で実行する
９０秒後、各擬似ユーザは、５つのレスポンスタイム測定を３０秒の時間枠内で実行する。他の活動がシステム上で起こっていないため、ＶＳＩレスポンスタイム測定は、最小偏差で最適な結果を出すことになる。一例では、５つの測定は、以下の通りであり得る。
・Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄに新しい文書をロードする
・ファイルを開くダイアログを起動する
・ノートパッドにテキストファイルをロードする
・印刷するダイアログを起動する
・ＰＳＴファイルをＺｉｐ形式にする
【００７３】
さらなる実施形態では、これらの測定の代わりにまたはそれに加えて他の測定を行うことができる。
【００７４】
ステップ５０８：ベースラインセッションをログオフする
ベースラインパフォーマンスが測定された時点で、ベースラインセッションはログオフされ、従って、ベースラインセッションはＶＳＩアプリケーションテストにおける通常のワークロードに参加できるようになる。
【００７５】
ベースライン測定フェーズは、ステップ５１０で終了する。
【００７６】
ＶＳＩアプリケーションテスト
ここで、図６のフローチャートを参照すると、ベースライン測定フェーズの後、システムは、ＶＳＩアプリケーションテストの準備が整っている。ＶＳＩアプリケーションｖ４内では、複数のワークロード（軽度、中度、重度およびマルチメディア）が利用可能である。ＶＳＩアプリケーションｖ４がベンチマーキングに使用される際は、中度のワークロードを実行することができる。
【００７７】
ステップ６００：開始間隔を設定する
ステップ６００では開始間隔が設定される。実施形態では、開始間隔は、４８分（２８８０秒）であり得る開始ウィンドウを全セッションで除することによって設定することができる。例えば、テストのために２００人のユーザが構成される場合は、１セッションあたりの開始間隔は、各セッション間で２８８０／２００＝１４．４秒である。
【００７８】
ステップ６０２：すべてのランチャの間でセッションを均等に割り当てる
また、リモートデスクトップセッションの開始は、クライアント側でもかなりのリソースを使用する。通常、１つのランチャあたり５０を超えるセッションを開始しないことが推奨されるが、この制限は、使用されるプロトコルおよびクライアントが実行しているシステムの能力に大きく依存する。
【００７９】
ＶＳＩアプリケーションは、利用可能なランチャの間ですべてのセッションの分布および負荷平衡を等しく自動的に行うことができる。これは、テストの間の個々のランチャへの負荷を低減する。
【００８０】
ステップ６０４：計算された開始間隔で各セッションを開始する
ここでは、各セッションに対して計算された開始間隔を使用して、ＶＳＩアプリケーションテストに着手する。このステップでは、ＶＳＩアプリケーションｖ４は、対象ＶＤＩ／ＳＢＣデスクトップ上でユーザｘに対して中度のワークロードを開始することができる。ステップ６０４のさらなる詳細については、図７のフローチャートに関して以下で説明する。
【００８１】
ステップ６０６：すべてのセッションが開始されたか？
ステップ６０６は、すべてのセッションが開始されたかどうかをチェックする。開始されていなければ、ＶＳＩアプリケーションは、ステップ６０４に戻り、新しいセッションを開始する。開始されていれば、フローは、ステップ６０８に続く。ステップ６００の開始間隔の定義を考慮すると、４８分後、すべてのセッションがＶＳＩアプリケーションによって開始される。
【００８２】
ステップ６０８、６１０および６１２：ログオフタイムアウトは指定されているか？
ＶＳＩアプリケーション管理コンソールでは、ログオフタイムアウトを指定することができる。ログオフタイムアウトが指定されていない場合は、最後のセッションが開始された後、ステップ６１０でマニュアル停止命令が受信されるまでワークロードが続けられる。他方では、ログオフタイムアウトが指定されている場合は、システムは、最後のセッションが開始された後、その指定された時間にすべてのセッションを一度ログオフする。例えば、ログオフタイムアウトが６００秒に構成されている場合は、すべてのセッションは、最後のセッションが開始された後、１０分間ログオンされたままである。これらの１０分が経過した時点で、すべてのセッションは、自動的にログオフされる。
【００８３】
ＶＳＩアプリケーションテストは、ステップ６１４で終了する。
【００８４】
ステップ６０４の追加の詳細：ワークロード実行
図７のフローチャートは、ステップ６０４（図６）の追加の詳細を提供する。ＶＳＩアプリケーションｖ４内には複数のワークロードがある。実施形態では、ＶＳＩアプリケーションｖ４は、中度のワークロードを使用する。このワークロードは、４８分ループで平均リソースユーザをシミュレートする。ワークロードが終了した時点で、全テストがアクティブである限り、ループが再開される。
【００８５】
実施形態では、ワークロードは、１２分の４つの等しい部分にセグメント化される。各セグメントは、異なるテストアプリケーションでの生産性のフェーズを表す。後続のユーザの各々は、次の連続セグメントでそのワークロードを開始する。すなわち、ユーザ１はセグメント１を開始し、ユーザ２はセグメント２を開始し、ユーザ３はセグメント３を開始し、ユーザ４はセグメント４を開始し、ユーザ５はセグメント１を開始し、ユーザ６はセグメント２を開始するなどである。
【００８６】
セグメント化なしでは、シミュレーションループの終了時に使用されるワークロードアプリケーションは、ＶＳＩアプリケーションテストの間にはほとんど使用されない。ワークロードが各ユーザによってセグメントで開始されるため、４８分のテストの間にすべてのアプリケーションおよび生産性のすべてのフェーズが等しく使用され、テストされる。
【００８７】
セグメントを有することにより、ユーザシミュレーションループ長全体をはるかに長くすることができ、従って、より現実的である。ＶＳＩアプリケーションの他の実施形態では、すべてのテストアプリケーションのワークロードは、１２〜１４分の時間枠内に開始されて使用された。これは、現実世界の挙動と同様ではない。ＶＳＩアプリケーションｖ４内では、ワークロードはここでは４８分であり、従って、時間のアプリケーション起動の量は、ＶＳＩアプリケーションの他の実施形態と比べると低減される。ＶＳＩアプリケーションｖ４ワークロードは、「頂点」ワークロードのままである。これは、システムの現実世界の限界を理解する上で役立つ。しかし、アプリケーション起動の量が低減され、アプリケーションにおける編集時間が延長された新しいＶＳＩアプリケーションｖ４は、それをはるかに現実的なものにする。
【００８８】
ステップ７００および７０２：中度のワークロードを開始し、セッションＩＤを回収する
ステップ７００では、セッションに対する中度のワークロードが開始される。言及されるように、さらなる実施形態では、それは、他のワークロード（低い、高い、マルチメディア）であり得る。ＶＳＩアプリケーションユーザがシステムにログオンした時点で、そのセッションＩＤを回収する。これは、ユーザがログオンし、ＶＳＩアプリケーションワークロードを開始した際にシステム上で実行しているアクティブセッションの数である。
【００８９】
ステップ７０４：セグメントを決定し、特定のセグメントを開始する
セッションＩＤに基づいて、セグメント開始がユーザのために選ばれる。これは、ランダム化されないが、あらかじめ決定される。ワークロードのランダム化は、ベンチマーキング目的では好まれない。テストが同じシステム上で繰り返し実行される場合は、結果は、同一である必要がある。しかし、さらなる実施形態では、ワークロードのランダム化が想定される。
【００９０】
ステップ７０６：特定のセグメントを開始する
ステップ７０６では、特定のセグメントが開始される。それぞれのセグメントの各々において異なる操作を実行することができる。一例では、以下の通りである。
・セグメント１は、以下を実行する。
・Ｏｕｔｌｏｏｋを起動する：メッセージを閲覧および編集する
・Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒを起動し、ページを閲覧する
・セグメント２は、以下を実行する。
・Ａｄｏｂｅ  ＡｃｒｏｂａｔでＰＤＦを起動し、レビューする
・Ｗｏｒｄで文書をレビューし、編集する
・文書をＰＤＦに印刷する
・セグメント３は、以下を実行する。
・Ｅｘｃｅｌを起動し、シートを編集する
・プールからＦｒｅｅｍｉｎｄ（登録商標）マインドマップをロードし、レビューし、編集する
・プールからＭｉｃｒｏｓｏｆｔ（登録商標）ＰｏｗｅｒＰｏｉｎｔプレゼンテーションを起動し、レビューし、編集する
・セグメント４は、以下を実行する。
・Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒでウェブサイトを閲覧する
・Ｆｌａｓｈ  Ｇａｍｅを起動する
・２つの４８０ｐの映画の予告編をレビューする
・ＶＳＩアプリケーションフォトビューアのプールから写真をレビューする
【００９１】
上記で説明される操作は、実行された特定の操作（他の操作を追加するかまたは代用することができる）と特定の操作が実行される順番の両方に関して、実施形態で異なり得る。
【００９２】
ステップ７０８：次のセグメントを続けるかまたはセグメント１を開始する
セグメントが終了した時点で、ワークロードは、次のセグメントを続ける。セグメント４が終了すると、すべてのテストアプリケーションが閉じられ、次いで、セグメント１が再び開始される。
【００９３】
ステップ７１０：ログオフコマンドが与えられた際にログオフする
セッションは、ログオフコマンドが与えられた際にログオフされる。ログオフコマンドが与えられるまでは、すべてのセッションが続けられ、ワークロードを繰り返す。ログオフコマンドは、上記のステップ６１０および６１２で説明されるようなものである。
【００９４】
セグメントおよびＶＳＩレスポンスタイム機構
ここで、図８のフローチャートを参照すると、ＶＳＩアプリケーションｖ４は、各セッション内でテストアプリケーションにおいて操作が実行されると、ＣＰＵおよびコンポーネントのレスポンスタイムを測定する。
【００９５】
ステップ８０２、８０４：前のセグメントからのすべての開いているアプリケーションが起動されたか？ 
セグメントが開始された後、上記のステップ７０６で説明されるように、ＶＳＩアプリケーションは、ステップ８０２において、前のセグメントからのすべてのアプリケーションが起動されたかどうかをチェックする。例えば、開始されたセグメントがセグメント１である場合は、他の前のセグメントはない可能性がある。しかし、開始されたセグメントがセグメント３である場合は、ＶＳＩアプリケーションは、セグメント１および２の両方からのアプリケーションが開始され、背景で実行されていることを確認するためにチェックすることができる。アプリケーションが前のセグメントで起動されていない場合は、まず、ステップ８０４において、現セグメントを続ける前にアプリケーションが起動される。これにより、それが最初に起動されたものである時でさえ、セグメントの相対負荷が常に同じであることが保証される。
【００９６】
ステップ８０６：ＶＳＩレスポンスタイム測定を実行する
一例では、ＶＳＩレスポンスタイムは、各セグメントの間に３回測定される。レスポンスタイムは、さらなる実施形態では、セグメントにおいてより多いまたはより少ない回数で測定することができる。ＶＳＩアプリケーションｖ４では、測定は、他の実施形態と比べて、システムパフォーマンスをより良く表すために最適化されている。また、測定の重み付けは、パフォーマンスボトルネックをより良く表すために変更された。以下の操作は、ＶＳＩアプリケーションｖ４レスポンスタイム測定の一部であり得る。
・大きなテキストファイルでノートパッドアプリケーションを起動する
・ファイルを開くダイアログを起動する
・印刷するダイアログを起動する
・圧縮なしでＰＳＴファイルをＺｉｐ形式にする
・高圧縮でＰＳＴファイルをＺｉｐ形式にする
・文書プールから新しい文書でＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄを起動する
【００９７】
これらの動作の開始時間は、後の分析のためにＶＳＩアプリケーションシェアに格納される。さらなる実施形態では、これらの動作に加えてまたはその代わりに、他の動作を実行できることが理解されている。
【００９８】
ステップ８０８：ワークロードを続ける
ＶＳＩレスポンスタイム測定後、ワークロードが続けられ、アプリケーションの起動、文書の閲覧および編集のような現実世界のユーザ操作をシミュレートする。
【００９９】
ステップ８１０：ＶＳＩアプリケーションアイドルバッファを実行する
ＶＳＩアプリケーションアイドルバッファは、システムにストレスがかかっている間、ワークロードがシステムへの同じ影響を有することを保証する。システムにストレスがかかった時点で、ワークロードのユーザ操作は、実行により多くの時間を要するようになる。アイドル時間バッファは自動的に調整（低減）され、従って、ワークロードセグメントの全体の長さは常に１２分であり得る。言及されるように、ループが４８分より長いまたは短い場合、セグメントの長さは、相応に異なり得る（ループの１／４である）。
【０１００】
ＶＳＩＭａｘ  ｖ４計算
テストが終了した時点で、ＶＳＩＭａｘ  ｖ４を計算することができる。ＶＳＩＭａｘの他の実施形態（ＣｌａｓｓｉｃおよびＤｙｎａｍｉｃ）は、システムが飽和していなかった際は計算することができなかった。ＶＳＩＭａｘ  ｖ４では、このことは要件ではない。システムが飽和しておらず、平均レスポンスタイムレイテンシ閾値を超えることなく全テストを完了できる際は、ＶＳＩＭａｘ  ｖ４は、開始されたアクティブセッションの最大数と見なされるであろう。
【０１０１】
実施形態では、以下の操作は、ＶＳＩＭａｘ  ｖ４計算の一部である。
・大きなテキストファイルでＶＳＩアプリケーションノートパッドを起動する
・ファイルを開くダイアログを起動する
・印刷するダイアログを起動する
・圧縮なしでＰＳＴファイルをＺｉｐ形式にする
・高圧縮でＰＳＴファイルをＺｉｐ形式にする
・文書プールから新しい文書でＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄを起動する
【０１０２】
さらなる実施形態では、これらの動作に加えてまたはその代わりに、他の動作を実行できることが理解されている。
【０１０３】
レスポンスタイムは、測定タイプごとに異なり得る。従って、これらの操作のレスポンスタイムは、合計に追加される前に重み付けすることができる。重み付けは、異なる動作に対するレスポンスタイムが総レスポンスタイムにおいて等しい影響を有することを保証するために適用される。例えば、圧縮でＺｉｐ形式にすることには約２８００ｍｓを要し、圧縮なしでＺｉｐ操作を行うことには７５ｍｓしか要さない場合がある。圧縮でＺｉｐ形式にすることは、小さな乗数で重み付けすることができ、圧縮なしでＺｉｐ操作を行うことは、より大きな乗数で重み付けすることができる。これにより、各活動が総レスポンスタイムへの等しい影響を有することが保証される。
【０１０４】
ＶＳＩＭａｘの代替の実施形態と比べると、この重み付けは、システムパフォーマンスをより良く表す。ＶＳＩ  ＣｌａｓｓｉｃおよびＤｙｎａｍｉｃインデックスとは対照的に、すべての操作は、ＶＳＩＭａｘ  ｖ４全体では、同じまたは同様の重みを有する。ＶＳＩＭａｘ  ＣｌａｓｓｉｃとＤｙｎａｍｉｃインデックスの両方では、例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄを開くことは、他の活動よりも、全体的にはるかに大きな影響を持っていた。以下の操作およびレスポンスタイムへの重み付けは、ＶＳＩＭａｘの計算の一例に適用される。
・大きなテキストファイルでＶＳＩノートパッドを起動する：０．５
・ファイルを開くダイアログを起動する：４
・印刷するダイアログを起動する：１．２５
・圧縮なしでＰＳＴファイルをＺｉｐ形式にする：６
・高圧縮でＰＳＴファイルをＺｉｐ形式にする：０．１７５
・文書プールから新しい文書でＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄを起動する：０．１５
【０１０５】
この重み付けは、ベースラインおよび正常なＶＳＩレスポンスタイムに適用される。これらの操作および割り当てられた重み付けは、単なる例示である。示されるものに対して他の操作を追加するかまたは代用することができ、他の重み付けを適用することができる。
【０１０６】
ＶＳＩアプリケーションｖ４における平均ＶＳＩＭａｘ  ｖ４ベースラインレスポンスタイム（ＶＳＩベースとも呼ばれる）は、ベースラインフェーズ（図４）に記録された結果から計算される。一例では、合計で３０のＶＳＩレスポンスタイムサンプルが、５つのベースラインセッションによって採取される。ＶＳＩベースがシステムの最適パフォーマンスを表すことを保証するため、最上位の１５の結果を平均計算から取り除くことができる。まぐれの低い測定値が非現実的に結果に影響を及ぼさないことを保証するため、最下位の２つの結果が平均ＶＳＩベース計算から取り除かれる。廃棄された高いおよび低い値の数は、さらなる実施形態において異なり得る。平均ＶＳＩＭａｘベースラインレスポンスタイム（ＶＳＩベース）は、残りの１３のＶＳＩレスポンスタイム測定上で計算される。ＶＳＩアプリケーションｖ４におけるＶＳＩＭａｘ平均レスポンスタイムは、システムにログオンしたアクティブユーザの数に対して計算される。
【０１０７】
一例では、５つのＶＳＩレスポンスタイムサンプルが平均され、「アクティブ」セッションの数の４０％がプラスされる。例えば、アクティブセッションの数が１００である場合、最新の５＋４０（１００の４０％）＝４５のレスポンスタイム測定が平均計算のために使用される。
【０１０８】
ノイズ（予想外のスパイク）を計算から取り除くため、ＶＳＩレスポンスタイムサンプルの最上位の５％および最下位の５％（最低でも最上位の１つと最下位の１つのサンプルで）を平均計算から取り除くことができる。その結果、１００人のアクティブユーザで、最後の３１のＶＳＩレスポンスタイムサンプルが採取される。それらの４５のサンプルから、最上位の２つのサンプルが取り除かれ、最下位の２つの結果が取り除かれる（４５の５％＝２．２５、四捨五入して２）。６０人のユーザでは、平均は、４１の残りの結果上で計算される。
【０１０９】
平均ＶＳＩレスポンスタイム結果によってＶＳＩベース＋２６００ｍｓレイテンシ閾値に達すると、ＶＳＩＭａｘ  ｖ４に達する。ＶＳＩベースに加えられるレイテンシは、さらなる実施形態では、２６００ｍｓより多くとも少なくともよい。テスト済みのシステム次第で、ＶＳＩＭａｘレスポンスタイムは、ベースライン平均の２〜３×に増加し得る。エンドユーザコンピューティングでは、レスポンスタイムの３×の増加は、ベースラインと比べて、通常、許容可能と考えられる最大パフォーマンス低下と見なされる。
【０１１０】
言及されるように、ＶＳＩＭａｘ  Ｄｙｎａｍｉｃインデックスでは、レイテンシ閾値は、テスト開始時、ベースライン測定値に依存していた。ベースライン測定値の２５％は、レイテンシ閾値に加えられた。ほとんどのテストにおいてこのことは問題ではなかったが、いくつかの事例（特に、システムパフォーマンスが２つの異なる構成間で非常に近かった時）では、単に、より高いベースライン結果がより高いレイテンシ閾値をより低速のシステムに与えたことを理由に、より低速のシステムがより高いＶＳＩＭａｘスコアを得た可能性がある。ＶＳＩＭａｘ  ｖ４では、このレイテンシ閾値は２６００ｍｓに固定され、それにより、特に、異なるベースライン結果を有する際に、２つの異なるシステム間のより良い比較が提供される。最終的に、ＶＳＩＭａｘ  ｖ４では、システムのパフォーマンスは、総平均レスポンスタイムによって決定されず、システムが負荷の下で有するレイテンシによって決定される。すべてのシステムに対し、これは、２６００ｍｓ（重み付けされた）であり得る。言及されるように、さらなる実施形態では、それより高くとも低くともよい。
【０１１１】
総レスポンスタイムの閾値は、重み付けされたベースラインフェーズレスポンスタイムの平均＋２６００ｍｓである。システムが１５００ｍｓの重み付けされたベースラインレスポンスタイムの平均を有する際は、最大平均レスポンスタイムは、４１００ｍｓ（１５００＋２６００）より大きくないものであり得る。平均ベースラインが３０００である場合は、最大平均レスポンスタイムは、５６００ｍｓ（３０００＋２６００）より大きくないものであり得る。
【０１１２】
実施形態では、システムがその閾値を超える前に、ＶＳＩＭａｘ  ｖ４が決定される。例えば、システム上のＶＳＩＭａｘ平均が８０人のユーザにおけるＶＳＩ閾値を超える際は、ＶＳＩＭａｘは７９である。
【０１１３】
テストの間に平均ＶＳＩレスポンスタイムが閾値を超えない時は、ＶＳＩＭａｘは、ここでは、開始されたユーザの最大数と考えられる。この手法は、ＶＳＩＭａｘ閾値を超えるシステムの飽和が常に必要とされたように、前のＶＳＩＭａｘ方法（ＣｌａｓｓｉｃおよびＤｙｎａｍｉｃ）と比べて、根本的に異なる。
【０１１４】
ＶＳＩＭａｘ  ｖ４インデックスは、平均ベースラインＶＳＩレスポンスタイム結果で報告することできる。例えば、「ＶＳＩＭａｘ  ｖ４は、１５２６ｍｓのベースラインで１２５であった」が挙げられる。これは、システムの比較において役立ち、システムのより完全な理解を与える。ベースラインパフォーマンスは、システムが個々のユーザに与えることができる最高のパフォーマンスを理解する上で役立つ。ＶＳＩＭａｘは、システムに対する総ユーザキャパシティがどのようなものかを示す。これらの２つは、自動的に関係および関連付けられない。例えば、３．６ＧＨＺで起動している超高速のデュアルコアＣＰＵを有するサーバを２．２６ＧＨＺで起動している１０コアＣＰＵと比較すると、デュアルコアマシンは、１０コアマシンより良いパフォーマンスを個々のユーザに与える。このことは、ベースラインＶＳＩレスポンスタイムによって示される。このスコアが低いほど、個々のユーザが予期できるパフォーマンスが良くなる。しかし、より低速の１０コアＣＰＵを有するサーバは、より高速のデュアルコアシステムより大きなキャパシティを有する。このことは、ＶＳＩＭａｘ  ｖ４によって示され、ＶＳＩＭａｘが高いほど、より大きな総ユーザキャパシティを予期することができる。
【０１１５】
図１に示されるＶＳＩアプリケーション、テストアプリケーション、データ格納およびコンポーネントは、各々が別個のコンピューティングシステム上で動作することができるか、または、これらのコンポーネントのうちの２つ以上を単一のコンピューティングシステムに統合することができる。これらのコンポーネントのいずれかまたはすべてのためのコンピューティングシステムは、様々な異なるタイプのコンピューティングデバイスのいずれかであり得る。これらのいずれかを説明できるサンプルコンピューティング環境３００が図９に関して以下で示され、説明される。発明のシステムは、多くの他の一般用途または特殊用途コンピューティングシステム、環境または構成で動作可能である。発明のシステムでの使用に適したものであり得る周知のコンピューティングシステム、環境および／または構成の例は、これらに限定されないが、パーソナルコンピュータ、サーバコンピュータ、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス、プログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、ラップトップおよびパームコンピュータ、ハンドヘルドデバイス、上記のシステムまたはデバイスのいずれかを含む分散型コンピューティング環境、ならびに、同様のものを含む。
【０１１６】
図９を参考すると、発明のシステムを実装するための例示的なシステムは、コンピュータ３１０という形態の一般用途コンピューティングデバイスを含む。コンピュータ３１０のコンポーネントは、これらに限定されないが、処理ユニット３２０、システムメモリ３３０、および、様々なシステムコンポーネントを結合する（システムメモリを処理ユニット３２０へ結合することを含む）システムバス３２１を含み得る。システムバス３２１は、様々なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バスおよびローカルバスを含む、いくつかのタイプのバス構造のいずれかであり得る。制限ではなく、例示として、そのようなアーキテクチャは、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子規格協会（ＶＥＳＡ）ローカルバス、および、メザニン（Ｍｅｚｚａｎｉｎｅ）としても知られている周辺機器相互接続（ＰＣＩ）バスを含む。
【０１１７】
コンピュータ３１０は、様々なコンピュータ可読媒体を含み得る。コンピュータ可読媒体は、コンピュータ３１０によるアクセスが可能な利用可能ないかなる媒体でもあり得、揮発性媒体と不揮発性媒体、着脱可能と着脱不能媒体の両方を含む。制限ではなく、例示として、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含み得る。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータなどの情報を格納するためのいかなる方法または技術でも実装される、揮発性と不揮発性、着脱可能と着脱不能媒体の両方を含む。コンピュータ記憶媒体は、これらに限定されないが、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、または、所望の情報の格納に使用できるおよびコンピュータ３１０によるアクセスが可能な他の任意の媒体を含む。通信媒体は、通常、搬送波または他の輸送メカニズムなどの変調データ信号において、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータを具体化し、いかなる情報搬送媒体も含む。「変調データ信号」という用語は、信号で情報を符号化するためにそのような方法で設定または変更されたその特性のうちの１つもしくは複数を有する信号を意味する。制限ではなく、例示として、通信媒体は、有線ネットワークまたは有線直結などの有線媒体や、音響、ＲＦ、赤外線および他の無線媒体などの無線媒体を含む。上記のいずれかの組合せもまた、コンピュータ可読媒体の範囲内に含まれる。
【０１１８】
システムメモリ３３０は、ＲＯＭ  ３３１およびＲＡＭ  ３３２などの揮発性および／または不揮発性のメモリの形態のコンピュータ記憶媒体を含む。起動中になど、コンピュータ３１０内の要素間で情報を転送する上で役立つ基本的なルーチンを含む基本的な入力／出力システム（ＢＩＯＳ）３３３は、通常、ＲＯＭ  ３３１に格納される。ＲＡＭ  ３３２は、通常、処理ユニット３２０によって即座にアクセス可能なおよび／または現在動作されているデータおよび／またはプログラムモジュールを含む。制限ではなく、例示として、図９は、オペレーティングシステム３３４、アプリケーションプログラム３３５、他のプログラムモジュール３３６およびプログラムデータ３３７を示す。
【０１１９】
また、コンピュータ３１０は、他の着脱可能／着脱不能、揮発性／不揮発性のコンピュータ記憶媒体も含み得る。単なる例示として、図９は、着脱不能の不揮発性の磁気媒体から読み取るかまたは着脱不能の不揮発性の磁気媒体に書き込むハードディスクドライブ３４１、および、着脱可能の不揮発性の磁気ディスク３５２から読み取るかまたは着脱可能の不揮発性の磁気ディスク３５２に書き込む磁気ディスクドライブ３５１を示す。コンピュータ３１０は、光媒体から読み取るおよび／または光媒体に書き込むための光媒体読取デバイス３５５をさらに含み得る。
【０１２０】
例示的な動作環境で使用できる他の着脱可能／着脱不能の揮発性／不揮発性のコンピュータ記憶媒体は、これらに限定されないが、磁気テープカセット、フラッシュメモリカード、ＤＶＤ、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭおよび同様のものを含む。ハードディスクドライブ３４１は、通常、インタフェース３４０などの着脱不能メモリインタフェースを通じてシステムバス３２１に接続され、磁気ディスクドライブ３５１および光媒体読取デバイス３５５は、通常、インタフェース３５０などの着脱可能メモリインタフェースによってシステムバス３２１に接続される。
【０１２１】
上記で論じられ、図９に示されるドライブおよびその関連コンピュータ記憶媒体は、コンピュータ３１０のためのコンピュータ可読命令、データ構造、プログラムモジュールおよび他のデータの格納を提供する。図９では、例えば、ハードディスクドライブ３４１は、オペレーティングシステム３４４、アプリケーションプログラム３４５、他のプログラムモジュール３４６およびプログラムデータ３４７を格納するものとして示されている。これらのコンポーネントは、オペレーティングシステム３３４、アプリケーションプログラム３３５、他のプログラムモジュール３３６およびプログラムデータ３３７と同じかまたは異なるかのいずれかであり得る。オペレーティングシステム３４４、アプリケーションプログラム３４５、他のプログラムモジュール３４６およびプログラムデータ３４７は、ここでは、最低でも、それらが異なるコピーであることを示すために異なる番号が与えられている。ユーザは、キーボード３６２およびポインティングデバイス３６１（一般に、マウス、トラックボールまたはタッチパッドと呼ばれる）などの入力デバイスを通じてコマンドおよび情報をコンピュータ３１０に入力することができる。他の入力デバイス（図示せず）は、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナまたは同様のものを含み得る。これらのおよび他の入力デバイスは、システムバス３２１と結合されたユーザ入力インタフェース３６０を通じて処理ユニット３２０に接続される場合が多いが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）などの他のインタフェースおよびバス構造によって接続することができる。モニタ３９１または他のタイプの表示デバイスもまた、ビデオインタフェース３９０などのインタフェースを介してシステムバス３２１に接続される。モニタに加えて、コンピュータは、スピーカ３９７およびプリンタ３９６などの他の周辺出力デバイスも含み得、スピーカ３９７およびプリンタ３９６は、出力周辺インタフェース３９５を通じて接続することができる。
【０１２２】
コンピュータ３１０は、リモートコンピュータ３８０などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク接続環境で動作することができる。リモートコンピュータ３８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通のネットワークノードであり得、通常、図９ではメモリ記憶装置３８１のみが示されているが、コンピュータ３１０に関連して上記で説明される要素の多くまたはすべてを含む。図９で描写される論理接続は、ローカルエリアネットワーク（ＬＡＮ）３７１およびワイドエリアネットワーク（ＷＡＮ）３７３を含むが、他のネットワークも含み得る。そのようなネットワーク接続環境は、オフィス、企業規模のコンピュータネットワーク、イントラネットおよびインターネットでありふれたものである。
【０１２３】
ＬＡＮネットワーク接続環境で使用される際は、コンピュータ３１０は、ネットワークインタフェースまたはアダプタ３７０を通じてＬＡＮ  ３７１に接続される。ＷＡＮネットワーク接続環境で使用される際は、コンピュータ３１０は、通常、インターネットなど、ＷＡＮ３７３上で通信を確立するためのモデム３７２または他の手段を含む。内蔵型または外付け型であり得るモデム３７２は、ユーザ入力インタフェース３６０または他の適切なメカニズムを介してシステムバス３２１に接続することができる。ネットワーク接続環境では、コンピュータ３１０に関連して描写されるプログラムモジュールまたはその一部分は、リモートメモリ記憶装置に格納することができる。制限ではなく、例示として、図９は、メモリデバイス３８１上に存在するものとしてのリモートアプリケーションプログラム３８５を示す。示されるネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立するための他の手段を使用できることが理解されよう。
【０１２４】
いくつかの実施形態では、トランザクション管理システムのすべてまたは一部は、１つまたは複数のプロセッサ可読記憶装置上に格納され、１つまたは複数のプロセッサをプログラムするために使用されるソフトウェアにおいて実装することができる。再び図１０を参照すると、企業マネージャ２２０は、企業マネージャ２２０にまたは企業マネージャ２２０から伝送されたいくつかまたはすべてのデータに対してあるいは企業マネージャ上に格納されたデータのために上記で説明されるような高次圧縮スキームを実行するための符号化エンジン２３０および復号エンジン２３２を有するＣＯＤＥＣをさらに含む。エンジン２３０および２３２を含むＣＯＤＥＣは、その代替としてまたはその代わりに、それらのコンピューティングシステムから送信された、それらのコンピューティングシステムによって受信されたおよび／またはそれらのコンピューティングシステム上に格納されたデータを符号化するために、管理されたアプリケーション２００、ワークステーション２２４、２２６および／またはデータベース２２２をホスティングする１つまたは複数のコンピューティングシステム上で提供できることが理解されている。
【０１２５】
一般に、符号化エンジン２３２は、コンポーネント２００、２２０、２２２、２２４および２２６のうちの１つのコンポーネント上の記憶媒体から整数値を受信し、それらの値を符号化し、次いで、符号化された値をコンポーネント２００、２２０、２２２、２２４および２２６のうちの１つまたは複数のコンポーネントの記憶媒体上に格納することが可能である。実施形態では、符号化エンジン２３２は、符号化された値を出力し、次いで、それらの値を格納するために新しいファイルおよび／またはデータ構造が生成される。同様に、復号エンジンは、コンポーネント２００、２２０、２２２、２２４および２２６のうちの１つのコンポーネント上の記憶媒体から符号化された値を受信し、それらの値を復号し、次いで、コンポーネント２００、２２０、２２２、２２４および２２６のうちの１つまたは複数のコンポーネントに復号された値を出力する（恐らくは表示することを含む）ことが可能である。実施形態では、復号エンジン２３２は、整数値を出力し、次いで、それらの値を出力および／または記憶媒体上に格納するために新しいファイルおよび／またはデータ構造が生成される。
【０１２６】
一実施形態では、図１０のシステムのユーザは、閾値追跡時間を指定することによって、企業マネージャによって管理されたすべてまたはいくつかのエージェント上のトランザクション追跡に着手することができる。その実行時間がこの閾値レベルを超えるエージェント内のすべてのトランザクションが追跡され、企業マネージャ２２０に報告され、企業マネージャ２２０は、追跡情報への関心を登録した適切なワークステーションに情報を転送する。ワークステーションは、閾値を超えるすべてのトランザクションをリストするＧＵＩを提示する。リストされた各トランザクションに対し、追跡されたトランザクションにおいてどこで時間が費やされていたかをユーザが即座に理解できるようにする視覚化を提供することができる。
【０１２７】
前述の本発明の詳細な説明は、例示と説明の目的のために提示してきた。網羅的であること、または、開示される正確な形態に本発明を制限することを意図しない。上記の教示を踏まえると、多くの変更形態および変形形態が可能である。説明される実施形態は、本発明の原理およびその実践的な応用を最も良く説明するために選ばれ、それにより、当業者は、企図する特定の使用に適している通り、様々な実施形態において、様々な変更形態と共に、本発明を最も良く利用できるようになる。本発明の範囲は本明細書に添付される請求項によって定義されることが意図される。
【図１】
2016535890.tif 000005
【図２】
2016535890.tif 000006
【図３】
2016535890.tif 000007
【図４】
2016535890.tif 000008
【図５】
2016535890.tif 000009
【図６】
2016535890.tif 000010
【図７】
2016535890.tif 000011
【図８】
2016535890.tif 000012
【図９】
2016535890.tif 000013
【手続補正書】
【提出日】平成28年4月4日(2016.4.4)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
サーバベースのコンピューティングまたは仮想デスクトップインフラストラクチャのパフォーマンスおよび／またはキャパシティを評価するための方法であって、
ａ）擬似ユーザワークロードで前記インフラストラクチャをロードするステップと、
ｂ）擬似ユーザの数を増加するステップと、
ｃ）ベースラインレスポンスタイムおよび固定レイテンシを含むレスポンスタイムが、前記ステップａ）における前記インフラストラクチャの前記ロードおよび前記ステップｂ）における前記擬似ユーザの数の増加に起因して所定のレスポンスタイム閾値を超える際に、前記インフラストラクチャのキャパシティを決定するステップと
を備える、方法。
【請求項２】
前記ステップａ）が、ユーザワークロードから多くのテストアプリケーションを開始し、前記多くのテストアプリケーション内から操作を実行するステップを備える、請求項１に記載の方法。
【請求項３】
多くのテストアプリケーションを開始する前記ステップが、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｏｆｆｉｃｅ、Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ（登録商標）およびＡｄｏｂｅ  ＰＤＦ  Ｒｅａｄｅｒ（登録商標）からなる群からの２つ以上のテストアプリケーションを開始するステップを備える、請求項２に記載の方法。
【請求項４】
前記インフラストラクチャが、前記ステップｃ）が前記インフラストラクチャの前記キャパシティを決定する際に飽和する、請求項１〜３のいずれか一項に記載の方法。
【請求項５】
前記インフラストラクチャが、前記ステップｃ）が前記インフラストラクチャの前記キャパシティを決定する際に飽和しない、請求項１〜３のいずれか一項に記載の方法。
【請求項６】
前記ベースラインレスポンスタイムが、擬似ユーザワークロードで前記インフラストラクチャをロードする前記ステップａ）の前に実行されるベースラインフェーズにおいて決定される、請求項１〜５のいずれか一項に記載の方法。
【請求項７】
前記所定のレスポンスタイム閾値を超える際に、前記ベースラインレスポンスタイムおよび擬似ユーザの数を出力するステップをさらに備える、請求項１〜６のいずれか一項に記載の方法。
【請求項８】
前記ステップａ）が、前記インフラストラクチャによってホスティングされるユーザワークロードの数にわたる平均ワークロードを表す中度のワークロードで前記インフラストラクチャをロードするステップを備える、請求項１〜７のいずれか一項に記載の方法。
【請求項９】
データセンタにおいてサーバベースのコンピューティングまたは仮想デスクトップインフラストラクチャのパフォーマンスおよび／またはキャパシティを評価するための方法であって、
ａ）低いワークロードの下で前記インフラストラクチャのベースラインレスポンスタイムを決定するためにベースラインフェーズを実行するステップと、
ｂ）擬似ユーザワークロードで前記インフラストラクチャをロードするステップと、
ｃ）擬似ユーザの数を増加するステップと、
ｄ）前記ベースラインレスポンスタイムおよび固定レイテンシを含むレスポンスタイムが、前記ステップｂ）における前記インフラストラクチャの前記ロードおよび前記ステップｃ）における前記擬似ユーザの数の増加に起因して所定のレスポンスタイム閾値を超える際に、前記インフラストラクチャのキャパシティを決定するステップと
を備える、方法。
【請求項１０】
前記固定レイテンシが、前記ベースラインレスポンスタイムとは無関係である、請求項９に記載の方法。
【請求項１１】
前記ステップｂ）が、以下の操作、すなわち、
ｅ）ノートパッドアプリケーションを起動する
ｆ）ファイルを開くダイアログを起動する
ｇ）印刷するダイアログを起動する
ｈ）圧縮なしでＰＳＴファイルをＺｉｐ形式にする
ｉ）高圧縮でＰＳＴファイルをＺｉｐ形式にする、および、
ｊ）新しい文書でＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄを起動する
のうちの１つまたは複数を実行するステップを備える、請求項９又は１０に記載の方法。
【請求項１２】
ステップｅ）〜ｊ）の前記操作の各々を実行するために要する時間が、互いに関して重み付けされる、請求項１１に記載の方法。
【請求項１３】
データセンタにおいてサーバベースのコンピューティングまたは仮想デスクトップインフラストラクチャのパフォーマンスおよび／またはキャパシティを評価するための方法であって、
ａ）擬似ユーザワークロードで前記インフラストラクチャをロードするステップであって、前記擬似ワークロードが連続セグメントでロードされ、各連続セグメントが、異なる実行時間の長さを要する多くの操作を実行する、ステップと、
ｂ）擬似ユーザの数を増加するステップであって、連続する新しい擬似ユーザの各々が、最初に異なるセグメントを実行し、次いで連続セグメントの実行に進む、ステップと、
ｃ）レスポンスタイムが、前記ステップａ）における前記インフラストラクチャの前記ロードおよび前記ステップｂ）における前記擬似ユーザの数の増加に起因して所定のレスポンスタイム閾値を超える際に、前記インフラストラクチャのキャパシティを決定するステップと
を備える、方法。
【請求項１４】
レスポンスタイムが、ベースラインレスポンスタイムおよび固定レイテンシを含む、請求項１３に記載の方法。
【請求項１５】
前記連続セグメントが、最後のセグメントの後に最初のセグメントにループバックするループで実行される、請求項１３又は１４に記載の方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１３
【補正方法】変更
【補正の内容】
【００１３】
別の例では、本技術は、データセンタにおいてサーバベースのコンピューティングまたは仮想デスクトップインフラストラクチャのパフォーマンスおよび／またはキャパシティを評価するための方法であって、ａ）低いワークロードの下でインフラストラクチャのベースラインレスポンスタイムを決定するためにベースラインフェーズを実行するステップと、ｂ）擬似ユーザワークロードでインフラストラクチャをロードするステップと、ｃ）擬似ユーザの数を増加するステップと、ｄ）ベースラインレスポンスタイムおよび固定レイテンシを含むレスポンスタイムが前記ステップｂ）におけるインフラストラクチャのロードおよび前記ステップｃ）における擬似ユーザの数の増加に起因して所定のレスポンスタイム閾値を超える際にインフラストラクチャのキャパシティを決定するステップとを含む、方法に関する。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００１６
【補正方法】変更
【補正の内容】
【００１６】
【図１】本技術を実装できるネットワークアーキテクチャのブロック図である。
【図２】経時的なユーザ負荷を示すグラフである。
【図３】経時的なユーザ負荷を示すグラフである。
【図４】本技術の実施形態の動作を示すフローチャートである。
【図５】本技術の実施形態の動作を示すフローチャートである。
【図６】本技術の実施形態の動作を示すフローチャートである。
【図７】本技術の実施形態の動作を示すフローチャートである。
【図８】本技術の実施形態の動作を示すフローチャートである。
【図９】本システムの実装が可能なコンピューティングシステム環境のブロック図である。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００４０
【補正方法】変更
【補正の内容】
【００４０】
【表１】
2016535890.tif 000014
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００４５
【補正方法】変更
【補正の内容】
【００４５】
【表２】
2016535890.tif 000015
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００８９
【補正方法】変更
【補正の内容】
【００８９】
ステップ７０４：セグメントを決定する
セッションＩＤに基づいて、セグメント開始がユーザのために選ばれる。これは、ランダム化されないが、あらかじめ決定される。ワークロードのランダム化は、ベンチマーキング目的では好まれない。テストが同じシステム上で繰り返し実行される場合は、結果は、同一である必要がある。しかし、さらなる実施形態では、ワークロードのランダム化が想定される。
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】０１２６
【補正方法】変更
【補正の内容】
【０１２６】
一実施形態では、図１０のシステムのユーザは、閾値追跡時間を指定することによって、企業マネージャによって管理されたすべてまたはいくつかのエージェント上のトランザクション追跡に着手することができる。その実行時間がこの閾値レベルを超えるエージェント内のすべてのトランザクションが追跡され、企業マネージャ２２０に報告され、企業マネージャ２２０は、追跡情報への関心を登録した適切なワークステーションに情報を転送する。ワークステーションは、閾値を超えるすべてのトランザクションをリストするＧＵＩを提示する。リストされた各トランザクションに対し、追跡されたトランザクションにおいてどこで時間が費やされていたかをユーザが即座に理解できるようにする視覚化を提供することができる。
以下の項目は、国際出願時の特許請求の範囲に記載の要素である。
［項目１］
サーバベースのコンピューティングまたは仮想デスクトップインフラストラクチャのパフォーマンスおよび／またはキャパシティを評価するための方法であって、
ａ）擬似ユーザワークロードで前記インフラストラクチャをロードするステップと、
ｂ）擬似ユーザの数を増加するステップと、
ｃ）ベースラインレスポンスタイムおよび固定レイテンシを含むレスポンスタイムが、前記ステップａ）における前記インフラストラクチャの前記ロードおよび前記ステップｂ）における前記擬似ユーザの数の増加に起因して所定のレスポンスタイム閾値を超える際に、前記インフラストラクチャのキャパシティを決定するステップと
を備える、方法。
［項目２］
前記ステップａ）が、ユーザワークロードから数テストアプリケーションを開始し、多くのテストアプリケーション内から操作を実行するステップを備える、項目１に記載の方法。
［項目３］
多くのテストアプリケーションを開始する前記ステップが、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｏｆｆｉｃｅ、Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ（登録商標）およびＡｄｏｂｅ  ＰＤＦ  Ｒｅａｄｅｒ（登録商標）からなる群からの２つ以上のテストアプリケーションを開始するステップを備える、項目３に記載の方法。
［項目４］
前記インフラストラクチャが、前記ステップｄ）が前記インフラストラクチャの前記キャパシティを決定する際に飽和する、項目１に記載の方法。
［項目５］
前記インフラストラクチャが、前記ステップｄ）が前記インフラストラクチャの前記キャパシティを決定する際に飽和しない、項目１に記載の方法。
［項目６］
前記ベースラインレスポンスタイムが、擬似ユーザワークロードで前記インフラストラクチャをロードする前記ステップａ）の前に実行されるベースラインフェーズにおいて決定される、項目１に記載の方法。
［項目７］
前記所定のレスポンスタイム閾値を超える際に、前記ベースラインレスポンスタイムおよび擬似ユーザの数を出力するステップをさらに備える、項目１に記載の方法。
［項目８］
前記ステップａ）が、前記インフラストラクチャによってホスティングされるユーザワークロードの数にわたる平均ワークロードを表す中度のワークロードで前記インフラストラクチャをロードするステップを備える、項目１に記載の方法。
［項目９］
データセンタにおいてサーバベースのコンピューティングまたは仮想デスクトップインフラストラクチャのパフォーマンスおよび／またはキャパシティを評価するための方法であって、
ａ）低いワークロードの下で前記インフラストラクチャのベースラインレスポンスタイムを決定するためにベースラインフェーズを実行するステップと、
ｂ）擬似ユーザワークロードで前記インフラストラクチャをロードするステップと、
ｃ）擬似ユーザの数を増加するステップと、
ｄ）前記ベースラインレスポンスタイムおよび固定レイテンシを含むレスポンスタイムが、前記ステップａ）における前記インフラストラクチャの前記ロードおよび前記ステップｂ）における前記擬似ユーザの数の増加に起因して所定のレスポンスタイム閾値を超える際に、前記インフラストラクチャのキャパシティを決定するステップと
を備える、方法。
［項目１０］
前記固定レイテンシが、前記ベースラインレスポンスタイムとは無関係である、項目９に記載の方法。
［項目１１］
前記ステップｂ）が、以下の操作、すなわち、
ｅ）ノートパッドアプリケーションを起動する
ｆ）ファイルを開くダイアログを起動する
ｇ）印刷するダイアログを起動する
ｈ）圧縮なしでＰＳＴファイルをＺｉｐ形式にする
ｉ）高圧縮でＰＳＴファイルをＺｉｐ形式にする、および、
ｊ）新しい文書でＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄを起動する
のうちの１つまたは複数を実行するステップを備える、項目９に記載の方法。
［項目１２］
ステップｅ）〜ｊ）の前記操作の各々を実行するために要する時間が、互いに関して重み付けされる、項目１１に記載の方法。
［項目１３］
データセンタにおいてサーバベースのコンピューティングまたは仮想デスクトップインフラストラクチャのパフォーマンスおよび／またはキャパシティを評価するための方法であって、
ａ）擬似ユーザワークロードで前記インフラストラクチャをロードするステップであって、前記擬似ワークロードが連続セグメントでロードされ、各連続セグメントが、異なる実行時間の長さを要する多くの操作を実行する、ステップと、
ｂ）擬似ユーザの数を増加するステップであって、連続する新しい擬似ユーザの各々が、最初に異なるセグメントを実行し、次いで連続セグメントの実行に進む、ステップと、
ｃ）レスポンスタイムが、前記ステップａ）における前記インフラストラクチャの前記ロードおよび前記ステップｂ）における前記擬似ユーザの数の増加に起因して所定のレスポンスタイム閾値を超える際に、前記インフラストラクチャのキャパシティを決定するステップと
を備える、方法。
［項目１４］
レスポンスタイムが、ベースラインレスポンスタイムおよび固定レイテンシを含む、項目１３に記載の方法。
［項目１５］
前記連続セグメントが、最後のセグメントの後に最初のセグメントにループバックするループで実行される、項目１３に記載の方法。
【手続補正８】
【補正対象書類名】図面
【補正対象項目名】図８
【補正方法】変更
【補正の内容】
【図８】
2016535890.tif 000016
【国際調査報告】
2016535890.tif 000017
2016535890.tif 000018