フェーズ 1: 評価の範囲設定

このトピックでは、BizTalk Serverパフォーマンス評価のスコープ フェーズの側面について説明します。

パフォーマンス評価に参加するときの一般的な間違いは、パフォーマンス評価の範囲を過小評価することです。 十分なリソースと時間が事前に割り当てられない場合、パフォーマンス評価を担当するチームは、複雑な運用環境のような環境の構築とテストに必要なすべてのタスクを完了できません。 パフォーマンス評価に取り組むチームは、慎重に戦いを選択する必要があります。 ほとんどのパフォーマンス評価は非常に限られた期間内に実行されるため、チームは 1 つまたは 2 つ (最大で 3 つの主要なパフォーマンス目標) を特定して焦点を当てる必要があります。 テストするアプリケーションは、特定されたパフォーマンス目標に焦点を当てるように特別に開発する必要があり、他のすべてのテクノロジ変数を可能な限り考慮する必要があります。 このトピックでは、BizTalk Serverパフォーマンス評価のスコープ フェーズの側面について説明します。

パフォーマンス評価を開始する前の考慮事項

パフォーマンス評価のために他の作業を行う前に、次の要因を考慮する必要があります。 これらの要因は、スコープ フェーズの一般的な方向を決定するのに役立ち、パフォーマンス評価の出発点として適しています。

メッセージの読み込み

実稼働システムを実際に通過するメッセージの読み込みをレプリケートする方法を最初から考慮することが重要です。 たとえば、運用環境でメッセージの 20% のサイズが <20 KB の場合、50% は <100 KB のサイズになり、残りの 30% は最大 1 MB のサイズになる可能性があります。これはラボでレプリケートすることが重要です。

テストするシナリオの簡単な詳細を作成する

テストされるテスト ケースを特定したら、それらに関連する主要なコンポーネントを特定することが重要です。 これには、BizTalk Server コンポーネント (メッセージングやオーケストレーションなど) と、MQSeries や SAP などのサードパーティ製テクノロジを含むその他のコンポーネントの両方が含まれます。 ラボの複雑さを測定するのに役立ち、エンゲージメント中に必要な技術的スキルを計画できるようになるため、これらのすべてを最初から認識することが非常に重要です。

使用するアダプターを特定する

パフォーマンス評価ラボでは、運用環境で使用される実際のアダプターを使用することが非常に重要です。 運用環境で使用されている実際のアダプターを使用しないと、異なるアダプターのパフォーマンスが大きく異なるため、問題が発生します。 たとえば、ファイル アダプターは最も高速なBizTalk Server アダプターの 1 つですが、一部のシステムに必要な機能の一部が不足しています。特に、ファイル アダプターはトランザクションをサポートしていません。 トランザクションのサポートでは、MSDTC トランザクションのコンテキスト内でメッセージを読み取り、メッセージ ボックス データベースに書き込む機能が提供されます。 トランザクションのサポートにはオーバーヘッドが発生します。 したがって、ファイル アダプターを使用して、トランザクションのサポートを必要とする運用シナリオをシミュレートすることは、実行可能な比較ではありません。 このシナリオでは、実稼働システムの実際のパフォーマンスを反映する可能性が非常に低いため、パフォーマンス結果は本質的に無効です。

パフォーマンス評価に必要な時間を見積もる

パフォーマンス評価に必要な時間を見積もるには、次のガイドラインを使用します。

• テスト環境を設定するための準備時間を 2 週間割り当てます。 1 週間を使用して、必要なインフラストラクチャ、ソフトウェア コンポーネントを構築し、ソフトウェア更新プログラムを適用します。 2 週目は、BizTalk Server運用環境を複製する特定の環境の設定専用になります。

• パフォーマンス評価中に分析されるテスト ケースごとに、追加の週を割り当てます。

• 実際のパフォーマンス評価の最後に 1 週間を割り当てて、パフォーマンス評価の結果を文書化します。

  そのため、2 つのテスト ケースを含む一般的なパフォーマンス評価の場合、評価を完了するための推定時間は次のようになります。

  (準備時間の 2 週間) + (実際のパフォーマンス評価の 2 週間) + (結果を文書化する 1 週間) = 合計 5 週間。

パフォーマンス評価の文書化

パフォーマンス評価のスコープの一環として、評価の詳細をエンゲージメントの概要に記載する必要があります。 このドキュメントでは、パフォーマンス評価の目標と目標、利害関係者、マイルストーンを明確に定義する必要があります。 このドキュメントは、パフォーマンス評価のロードマップとして機能し、すべての関係者がエンゲージメントの詳細に同意し、パフォーマンス評価が確実に順調に進めるようにするのに役立ちます。このドキュメントは、パフォーマンス評価全体を通じて更新し、パフォーマンス評価の終了時に結果の概要を含める必要があります。

ゴールと目標

スループットと待機時間の目標を慎重に定義 する - 最大にしようとしているパフォーマンス基準は何ですか? 通常、次のパフォーマンス測定の 1 つ以上が、BizTalk Serverパフォーマンス評価の焦点です。

• スループット – 通常、指定された時間間隔で処理できる時間単位あたりのメッセージ数として測定されます。 たとえば、スループットの目標は、3 時間の期間、1 秒あたり 100 メッセージを処理する機能として定義できます。

• 待機時間 – 通常、特定の時間間隔内でエンドツーエンドで処理できるすべてのメッセージの割合として定義されます。次に例を示します。

  • すべてのメッセージの 95% を 2 秒以内にエンドツーエンドで処理する必要があります。

  • すべてのメッセージの 100% を 4 秒以内にエンドツーエンドで処理する必要があります。

• ピーク負荷

• Xのバッチを完了する時間

• フラッドゲート復旧のシナリオ

• ハードウェアとソフトウェアを含む高度なアーキテクチャ

  パフォーマンス目標は、"ハードウェアとソフトウェアの制約が可能な限り高い X を達成する" という観点から測定する必要があります。 目標を事前に測定する方法を決定します。 たとえば、「カウンター ' XLang /s\orchestrations completed/second' で測定された X のエンドツーエンドの最大持続可能なスループット」などです。

望ましいパフォーマンスは達成可能ですか?

パフォーマンスに関する考慮事項を評価するときは、まず、使用可能なハードウェア リソースがパフォーマンス目標を達成するのに十分かどうかを判断する必要があります。 場合によっては、ハードウェアへの追加投資なしでは、目的のパフォーマンスが実現できない場合があります。 オーケストレーションの複雑さ、使用されるカスタム コード、メッセージが MessageBox データベースに保持される回数、外部システムの制限など、多くの要因がソリューションのパフォーマンスに影響を与える多くの要因によって、特定のハードウェア構成によってどのようなパフォーマンスが得られるか、または不可能かを判断するために使用できるマジック式はありません。 次の表は、特定のシナリオで特定のパフォーマンス目標を達成するために使用されるハードウェアの概要を示しています。

ハードウェア シナリオの例

使用可能なハードウェア インフラストラクチャが目的のパフォーマンスを達成するのに十分であると判断された後、BizTalk Serverパフォーマンス評価をスコープする場合は、次の点を考慮してください。

• 必要なアダプターやアクセラレータはどれですか?

• ソリューションにオーケストレーションを実装するための要件は何ですか?

• スループット要件を文書化する: ソリューションの持続可能な最大スループット要件は何ですか?

• 待機時間の要件: 要請-応答と要求/応答のシナリオに対して、ソリューションの応答性はどのくらい必要ですか?

• ドキュメントの読み込みがピークの期間からどの程度回復しますか?

• ソリューションの高可用性要件は何ですか?

• ソリューションのドキュメント追跡要件は何ですか?

• リモート Web サービスや他のシステムなどの依存アプリケーションのパフォーマンス特性は何ですか? 依存アプリケーションが必要な負荷に追いつかないと、それに応じてシステム全体のパフォーマンスが低下します。

スコープ フェーズ中に考慮するハードウェア情報

ソリューションをスコープする場合は、次を含む高度なハードウェア図を作成します。

• コンピューター アーキテクチャ (x86、x64、IA64 など)

• CPU 要件 (種類、速度、数、コア、ハイパースレッディングの使用など)

• 各コンピューターの RAM 要件

• ローカル ディスク ストレージ (種類、サイズ、速度)

• SAN (ストレージ要件: LUN の数。SAN カードの種類)

• ネットワーク カード (各コンピューターの数、100 メガビット/秒 (Mbps) と 1 ギガビット/秒 (1 Gbps))。

• ソリューションにファイアウォールをデプロイする方法

• ネットワーク負荷分散ハードウェアは使用されますか?

• 特定のコンピューターをクラスター化しますか?

スコープ フェーズ中に考慮するソフトウェア情報

ハードウェア情報は、パフォーマンス評価中に使用されるソフトウェア スタックであるため、同様に重要です。 次の情報を文書化する必要があります。

• 各コンピューターのオペレーティング システム (32 または 64 ビット、クラスター化されているかどうか)。

• 各コンピューターにインストールするサーバー ソフトウェア。

• 使用される仮想化ソフトウェア。

• COM+ ロールアップ修正や、必要なホスト修正など、通常はインストールされていない特定のソフトウェア機能SQL Server。

コードの変更がパフォーマンス評価の範囲内にあるかどうかを判断する

これは、スコープ プロセス中に決定する最も重要な事項の 1 つです。 BizTalk Serverおよび使用する基になるコンポーネント (SQL Server、Windows、IIS など) は、このガイドで説明するチューニング手法と構成変更を使用して最適化できます。 ただし、最適なパフォーマンスを得るためのアプリケーションが開発されていない場合は、これらのパフォーマンスの向上を妨げる可能性があります。 そのため、コードの変更は、アプリケーションがラボに入る前に完全なコード レビューが完了したと確信できる場合にのみ、スコープから削除する必要があります。 必要に応じて、オーケストレーション内の永続化ポイントの削除など、特定の変更のみを許可することに同意できます。

ロールと責任

パフォーマンス評価を実行する最も重要な領域の 1 つは、ロールと責任が明確に割り当てられていることを確認することです。 パフォーマンス評価の開始時に、次の主要なロールを割り当てる必要があります。

• エンゲージメント リード - エンゲージメント リードは、エンゲージメント全体をエンドツーエンドで所有する責任があります。 この役割は、通常、シニア コンサルタントまたはアーキテクトによって実行されます。 理想的には、この人はBizTalk Serverベースのシステムのチューニングの経験を持っている必要があります。 SQL Serverやサードパーティのものを含む他の技術に関する知識が望ましいです。 リードはすべての分野の専門家である必要はありませんが、これらの分野の専門家と協力して、適用している最適化を理解するために、少なくともテクノロジに関する実用的な知識が必要です。

• テスト デザイナー - ラボ中に実行されるテストの設計と実装に専念するユーザーが必要です。 これには、テストの作成に使用されるテスト フレームワークを決定し、各テストをテストしてラボの要件を満たしていることを確認し、テストを実行する責任者がクライアントの使用方法を認識していることを確認する必要があります。

• 環境所有者 - 運用環境BizTalk Server環境を正確に反映する代表的な環境をラボ内に配置することが重要です。 このロールを実行するユーザーは、使用されているソフトウェアとハードウェア スタックの各項目を確認し、大きな違いがないことを検証する責任を負います。 たとえば、32 ビット プラットフォームで実行する場合SQL Server 2008 R2 では、物理アドレス拡張 (PAE) またはアドレス ウィンドウ拡張機能 (AWE) を使用せずに、4 GB の物理メモリのみをアドレス指定できます。 SQL Server 2008 R2 では、64 ビットから 1 テラバイトまでのメモリに対処できます (これは、Windows Server 2008 R2 でサポートされている現在の最大物理メモリです)。 したがって、お客様とラボ環境の大きな違いは、BizTalk ServerとSQL Serverによって使用される CPU のアーキテクチャです。 これらの明白な要因に加えて、Service Pack レベルやインストールされている修正プログラムなど、他のあまり明らかでない要因が、環境のパフォーマンスに影響を与える可能性があります。

• ビルド環境のリード - パフォーマンス評価の詳細な仕様が作成されたら、環境を構築する責任を誰かに割り当てる必要があります。 これには、ハードウェアとソフトウェア のスタックが含まれます。 多くの場合、1 人の個人がこれに対して責任を負います (これは多くの場合、環境所有者です)。 ただし、大企業では、環境所有者は、ソリューションのさまざまなコンポーネントを担当するさまざまなチーム間の連絡担当者である必要がある場合があります。 たとえば、1 つのチームが Windows ビルドを担当し、別のチームがSQL Serverを担当し、もう 1 つのチームがBizTalk Serverを担当する場合があります。

• 展開リード - アプリケーションがBizTalk Serverに正しくデプロイされていること、正しいバインディングが構成されていること、およびカスタム構成が適用されていることを確認する担当者が必要です。 このロールには、ソリューションに関する完全な知識が必要であり、アプリケーションをパッケージ化してアプリケーションをデプロイし、ラボ環境内で機能している状態であることを検証するための知識が必要になります。

• 製品スペシャリスト – パフォーマンス評価に必要な製品スペシャリストを特定することが重要です。 必要な正確なスキルは、BizTalk Serverアプリケーションの設計と目的によって異なります。

  必要な最も一般的な製品スペシャリストのスキルの 1 つは、パフォーマンス チューニングSQL Serverに関する広範な知識です。 これらのスキルは 2 つの目的で必要です。1 つ目は、BizTalk データベースのパフォーマンスを最適化するためにSQL Server最適化を実行することが多く、2 つ目は、多くの BizTalk ソリューションがカスタム データベースを使用することです。 SQL Server環境に正しい最適化が適用されていない場合、カスタム データベースの使用がソリューションのボトルネックになる可能性があります。 適切なデータベース最適化を特定して適用するには、通常、次のSQL Serverスキルが必要です。

  • 既存のストアド プロシージャSQL Server最適化する機能など、ストアド プロシージャ コードを完全に理解します。

  • 不足しているデータベース インデックスを識別して構築する機能。

  • データベースを複数のファイルに分割するスクリプトを記述する機能。

    Note

    この最適化の適用の詳細については、「 Databases2 のファイル グループの最適化」を参照してください。

  • SQL Server 2008 R2 パフォーマンス ダッシュボード レポートを使用してパフォーマンスの問題を特定する機能。

    パフォーマンス評価に関連する各スペシャリスト テクノロジについて、SQL Serverに関して上記のように要件の一覧を定義する必要があります。 これにより、取得したリソースが、それらのリソースに必要なものについて明確な期待を持つようになります。 パフォーマンス評価中に専門的な知識を頻繁に必要とするもう 1 つのテクノロジーは、WEBsphere MQ です。 以下のリストは、WebSphere MQ 製品スペシャリストの要件仕様を示しています。

  • MQSeries のモニター、保守、およびカスタマイズの経験。

  • 新しいバージョンの MQSeries のインストールと移行の経験。

  • MQSeries のパフォーマンスを分析および調整する機能。

  • MQSeries 問題分析を実行します。

  • MQSeries のセキュリティー、管理、リカバリー、自動化に関連するプロセスと手順に関する知識。

• ドキュメント リーダー - パフォーマンス評価全体を通じてラボ ドキュメントをエンドツーエンドで継続的に更新することが非常に重要です。 運用環境で最適化が正常に適用され、システムが目的のレベルのパフォーマンスを得るまで、ラボ エンゲージメントの全体的な成功を判断しないでください。 これを行うには、次の情報の詳細なレコードを保持することが不可欠です。

  • ラボの結果の概要

  • 未解決の問題

  • 解決した問題

  • ラボのタイムライン

  • ラボの進行状況

  • カテゴリ別に実装された最適化

  • 最適化を時系列順に実装 (運用システムで同じ順序で適用できるようにするため)

  • アーキテクチャの概要図

  • テストするシナリオの詳細

  • 関連するサード パーティのテクノロジ

  • ラボのハードウェア図

  • 連絡先リスト

  • 詳細なハードウェア インベントリ

  • 完全な詳細な結果を含む付録

• 開発者 - 開発者が必要かどうかは、エンゲージメントの範囲によって大きく異なります。 コード ベースがロックダウンされ、ラボでインフラストラクチャとプラットフォームの最適化のみをテストする場合は、開発者のサービスは必要ありません。 この種のシナリオは、実稼働サーバーの "稼働開始" 日の直前にパフォーマンス テストが実行される場合に発生する可能性があります。 この時点で、コードはロックダウンされ、完全な回帰テストは完了するか進行中である必要があります。 ラボで導入されたコードに変更を加えた場合、回帰が発生する可能性があるため、運用システムにリスクが生じる可能性があります。 コードの変更が許可されている場合、通常は開発者が必要です。 次の一覧は、BizTalk Serverパフォーマンス評価に取り組む開発者が通常必要とするスキルを示しています。

  • オーケストレーションに関するパフォーマンスの問題を特定して修正する機能

  • パイプラインのパフォーマンスの問題を特定して修正する機能

  • .NET に関する知識には、次の情報が含まれます。

    • エンタープライズ ライブラリ

    • Visual Studio F1 プロファイラーの専門知識

    • Microsoft Visual Studio 2010 Ultimate または Visual Studio Test Professional 2010

• テスト リード - 正確で完全で完全な結果セットが得られるようにすることが重要です。 テスト リーダーは、必要な情報がキャプチャされ、適切に分析され、各テストの実行後に適切に配布されるようにする責任があります。 データをキャプチャする方法を検討することが重要です。通常、テスト データは Excel スプレッドシートを使用したプレゼンテーションに適しています。 次の一覧は、ラボ中に実行される各テストに対してキャプチャする必要があるデータを示しています。

  • テスト実行番号

  • Date

  • 処理されたメッセージの合計数

  • 1 秒あたりに処理されるメッセージ

  • 開始時刻

  • 停止時刻

  • テスト期間 (分)

  • 中断されたメッセージ/処理されたメッセージの合計数 – これは、BizTalk 管理コンソールから、またはパフォーマンス モニターを使用してBizTalk Serverパフォーマンス カウンターを測定することによってキャプチャできます。

  • 処理に失敗したメッセージの数

  • 正常に処理された # またはメッセージ

  • クライアント応答をテストする

  • クライアント プロセス期間の平均 (秒単位) - 通常、この値は、BizTalk Serverを使用して同期メッセージング ソリューションを実装するときに測定されます。この場合は、通常、エンド ユーザーがソリューションからの応答を待機している時間を表す平均クライアント期間の値を把握することが重要です。

  • クライアント プロセス期間の最大値 (秒単位)

  • クライアント プロセス期間の最小値 (秒単位)

  • BizTalk Server要求/応答の待機時間 (秒単位)

  • 1 秒あたりに完了したオーケストレーション

  • 時間に応じて処理されたメッセージの割合

  • Visual Studio Team System テスト ツールで使用される TestResultsLocation 変数の値。

  • BizUnit で使用される TestResultsLocation 変数の値。

  • コメントまたは推奨事項

    テスト リーダーは、結果を収集するだけでなく、各テストの実行を監視して傾向があるかどうかを確認する必要があります。 パフォーマンスの向上は、チームの残りの部分に伝える必要があり、パフォーマンスがどの程度向上したか、および改善を達成するためにどの最適化が適用されたかを示す必要があります。 1 日の終わりに、テスト リーダーがラボで実行されたテストの概要を提供することが重要です。 これにより、関係者はラボの継続的な進行状況を常に把握できます。 次の表は、この情報をサンプルの更新プログラムの電子メールにまとめる方法を示しています。

  テスト結果の概要

  Status	スループット	平均待機時間	%< 2 秒	テスト実行の数	BizTalk Server コンピューターの数	メッセージの数	平均メッセージ サイズ	期間
  スケール アウト	140 メッセージ/秒	0.777 秒	99.3%	2	6	270,000	609 バイト	30 分
  最高	50 メッセージ/秒	1.12 秒	99.12%	17	2	360,000	609 バイト	2 時間
  ベースライン	30 メッセージ/秒	1.52 秒	92.9 %	4	2	36,000	609 バイト	20 分
  目標	5 メッセージ/秒	< 2 秒	90%	-	2	-	-	-

パフォーマンス評価の開始時に必要なすべての成果物を定義する

BizTalk Serverパフォーマンス評価に着手する前に実施する必要がある成果物に同意することが重要です。 以下のセクションでは、パフォーマンス評価の開始時に実施する必要がある成果物について説明します。

• テスト対象のアプリケーション – パフォーマンス評価中に使用される完全なアプリケーションを使用できる必要があります。 パフォーマンス評価を開始する前にアプリケーションが完全に機能している状態であることが重要です。そうしないと、貴重なラボ テスト時間が失われるリスクがあります。

• 自動ビルドとデプロイの計画 - パフォーマンス評価に取り組む前に、BizTalk Server ソリューションをテストするために、自動化されたビルドとデプロイのプロセスを開発する必要があります。 アプリケーションのビルド プロセスを自動化すると、継続的な毎日のビルド プロセスを実行できます。その後、システムを介して機能フローをテストする一連のビルド検証テスト (BVT) を伴うことができます。 これにより、開発ライフサイクル全体を通じてコンパイルと機能の問題をより迅速かつ簡単に検出できます。 これは、ラボ内で、コードの変更が必要な場合は、更新されたソリューションが問題なく動作することを迅速に確認できることを意味します。 パフォーマンス ラボ用にアプリケーションを手動でビルド、デプロイ、構成することは、面倒でエラーが発生しやすい作業になる可能性があります。 そのため、自動化手法を使用して、次のビルドとデプロイのアクティビティを実行することをお勧めします。

  • ソース管理から最新のコードを取得します。

  • 完全なソリューションを構築します。

  • ソリューションを環境にデプロイします。

  • BizTalk アプリケーションを作成します。

  • .dll ファイルやバインドなどのBizTalk Server リソースを BizTalk アプリケーションに追加します。

  • バインド ファイルをインポートしてポートを作成し、オーケストレーションにバインドします。

  • BizTalk アプリケーションを Microsoft® Windows® インストーラー パッケージとしてエクスポートして、テスト環境または運用環境に展開できるようにします。

  Note

  自動ビルド プロセスの実装の詳細については、「ビルド プロセスの自動化」を参照してください。

  MSBuild は.NET Framework 2.0 と共に導入され、開発者は前述のようなタスクを自動化できます。 からダウンロードhttps://go.microsoft.com/fwlink/?LinkId=119288できる SDC タスク ライブラリには、いくつかのBizTalk Server固有の MSBuild タスクが含まれています。

• パフォーマンス評価中に使用されるテスト データ – 使用されるテスト データは、パフォーマンス評価の全体的な有効性と成功に大きな影響を与えます。 BizTalk Server アプリケーションがメッセージング、オーケストレーション、ルール エンジンを利用するシナリオを考えてみましょう。 ルール エンジンは、受信側のパイプライン コンポーネント内から呼び出され、メッセージの処理に使用されるオーケストレーションを決定します。また、フローを決定するために、さまざまなポイントでオーケストレーション内から呼び出されます。 ルール エンジンは、ルール ポリシーの実行が最適化されるようにキャッシュを実装します。 そのため、パフォーマンス評価中に 1 つのメッセージがテスト データとして使用されている場合、テスト結果が歪んで (キャッシュが原因で)、運用環境でレプリケートできない結果が得られる可能性があります。

  パフォーマンス評価中に使用されるテスト データは、実際の運用データまたは運用データのサブセットであることが理想的です。 テスト データでは、運用システムを通過するトラフィックの負荷とパターンもシミュレートする必要があります。 テスト データの要件を定義するときは、次の要素を考慮してください。

  • 特定の期間内にシステムを通過するメッセージの数 - これは通常、1 秒あたりのメッセージ数または 1 時間あたりのメッセージ数として表されます。

  • メッセージの種類 – メッセージはフラット ファイル、XML、またはバイナリですか?

  • メッセージの分布 – フラット ファイルの割合は何パーセントで、各 XML メッセージの種類に対してどの割合が使用されますか?

  • ピーク時の負荷処理要件 - 多くのシナリオでは、ピーク時以外に大規模なインターチェンジが処理される場合があります。 たとえば、大量の支払いバッチは、午前 0 時に銀行のシステムに転記される場合があります。 その場合は、テスト中にこれをレプリケートできることを確認してください。

  • メッセージの受信/送信に使用されるエンドポイント - 多くの環境では、異なる種類のメッセージを受信するように個別の受信場所が構成されています。 たとえば、フラット・ファイル・メッセージはファイル・アダプターを使用して受信することも、MQSeries アダプターを使用して XML メッセージを受信することもできます。 メッセージはすべて同じオーケストレーションで処理できますが、システムへのエントリ ポイントは異なります。 これらの異なる受信場所はそれぞれ別のホストでホストできます。実際、これを行うと、多くの場合、システムの全体的なパフォーマンスが向上します。

    次の表は、テスト データの仕様を決定するときにキャプチャする必要がある情報の例を示しています。

  サンプル テスト データの仕様

情報をテーブルに配置すると、いくつかの処理が完了します。 まず、関係者がテスト データに関して行われた仮定に簡単に同意できるようになります。 次に、パフォーマンス評価の潜在的な最適化を決定するために使用できる情報が提供されます。 たとえば、上の表では、すべての異なるデータ型を処理するために使用されるすべての受信場所が ReceiveHost BizTalk ホスト内でホストされていることがわかります。 つまり、このホストの各インスタンスは、さまざまな種類とサイズのデータ (XML やバイナリの圧縮不可能な PDF データなど) を処理します。 各ホスト インスタンスがBizTalk Server プロセス (BTSNTSVC.EXE) の 1 つのインスタンスである場合、これは処理のボトルネックになる可能性があります。 したがって、このシナリオでは、環境に対するすぐに明らかな最適化の 1 つは、各受信場所を独自のホストに分離するパフォーマンスの向上をテストすることです。 概要表形式でテスト データ情報にアクセスすると、このような単純な最適化を簡単に測定できます。

• 自動ロード テストとロード生成の計画 - パフォーマンス評価のテスト データ プロファイルが確立されたら、環境内でロード テストを実行する方法を検討することが重要です。 BizTalk Server 2010 ロード テストでは、Visual Studio 2010 ロード テストを使用しました。 Visual Studio 2010 を使用してロード テストを容易にする方法の詳細については、「 Visual Studio を使用して自動テストを容易にする」を参照してください。

参照

パフォーマンス評価のフェーズ