SharePoint Server 2010 での InfoPath Forms Services のパフォーマンスと容量の要件を見積もる

 

適用先: InfoPath Forms Services

トピックの最終更新日: 2016-11-30

この記事では、Microsoft SharePoint Server 2010 の InfoPath Forms Services の使用が Microsoft SharePoint Server 2010 を実行するトポロジに与える影響について、ガイダンスを示します。

この記事で説明されているテストは、以下の変数の変化にさまざまなファーム構成がどのように応答するかを評価するのに役立つように設計されました。

• さまざまな送信操作に対するフロントエンド Web サーバーのスケールアウト

• さまざまな InfoPath リスト操作に対するフロントエンド Web サーバーのスケールアウト

• フォームの複雑さがスループットに与える影響

SharePoint Server 2010 の容量計画の一般的な情報については、「パフォーマンスと容量の管理 (SharePoint Server 2010)」を参照してください。

この記事の内容:

• テスト ファームの諸特性

• テスト結果

• 推奨事項

テスト ファームの諸特性

この記事で示す容量とパフォーマンスに関する特定の数値は、現実の環境における数値とは異なります。ここで示す数値は、ある一定規模の環境を設計するための出発点を提供することを目的とします。初期のシステム設計が完了した後、構成をテストし、実際の環境におけるさまざまな要因にシステムが対応できるかどうかを判断します。

ハードウェア、設定、およびトポロジ

以下のセクションでは、これらのテストを完了するために使用したハードウェアとトポロジ、およびテスト シナリオについて説明します。

• ラボのハードウェア

• トポロジ

• テスト シナリオ

ラボのハードウェア

テスト結果の詳細を高いレベルで提供できるように、テストでは複数のファーム構成を使用しました。ファームは、1 ～ 6 台の Web サーバー、および Microsoft SQL Server 2008 データベース ソフトウェアを実行する 1 台のデータベース サーバーで構成されました。ロード テストは、Visual Studio Team System 2008 を使用して実行されました。テストには、2 台のエージェント コンピューターも含まれました。すべてのコンピューターは 64 ビットです。

次の表は、テストで使用されたハードウェアを示しています。

	Web サーバー	データベース サーバー	エージェント 1 およびエージェント 2
ロール	フロントエンド Web サーバー	SQL Server	エージェント
プロセッサ	2x Xeon L5420 @ 2.5 GHz (8 コア)	4x Xeon E7330 @ 2.4 GHz (16 コア)	2x Xeon L5420 @ 2.5 GHz (8 コア)
RAM	16 GB	32 GB	16 GB
オペレーティング システム	Windows Server 2008 R2	Windows Server 2008 R2	Windows Server 2008 R2
ストレージ: オペレーティング システム	4x 146 GB、10K RPM、RAID 0	2x 146 GB、15K RPM、RAID 1	4x 146 GB、10K RPM、RAID 0
ストレージ: バックアップ		3x 300 GB、15K RPM、RAID 5
ストレージ: SQL Server データ		9x 300 GB、15K RPM、RAID 5
ストレージ: SQL Server ログ		6x 300 GB、15K RPM、RAID 5
ネットワーク アダプターの数	1	4	1
ネットワーク アダプターの速度	1 GB/秒	1 GB/秒	1 GB/秒
認証	NTLM	NTLM	NTLM
ソフトウェアのバージョン	SharePoint Server 2010 (プレリリース版)	SQL Server 2008 SP1 CU6
SQL Server インスタンスの数		1
ロード バランサーの種類	Windows ネットワーク ロード バランシング	Windows ネットワーク ロード バランシング	該当なし
Information Rights Management (IRM) の設定	オフ	オフ
ウイルス対策の設定	インストールされていない	インストールされていない	インストールされていない

トポロジ

InfoPath 容量計画トポロジ

テスト シナリオ

このセクションではテスト シナリオを定義し、各シナリオで使用されたテスト プロセスの概要について説明します。テスト結果については、この記事の後半のセクションで説明します。

フォーム テンプレート

テストは、テキスト ボックス、ラジオ ボタン、およびドロップダウン リスト ボックスで構成されるフォーム テンプレートを使用して実行されました。このテンプレートをベースライン ソリューションと呼びます。コンテキスト用のフォーム テンプレートのスクリーン ショットを次に示します。

Passport アプリケーション フォーム

ベースライン ソリューションを使用して、派生フォーム テンプレートを作成しました。このフォーム テンプレートは、範囲が限定された変更をベースライン ソリューションのテンプレートに加え、そのテンプレートを新規テンプレートとして保存する方法によって作成されます。この方法では、フォーム設計のさまざまな操作と側面を比較できます。次の表に、テストで使用したさまざまなフォーム テンプレートを示します。

フォーム テンプレート	フィールドの数	送信の種類	検証ルールの数	初期要求の最適化	管理者による展開	メモ
ベースライン ソリューション	44	なし	4	はい	いいえ
Web サービス送信対応ベースライン ソリューション	44	Web サービス	4	はい	はい
ドキュメント ライブラリ送信対応ベースライン ソリューション	44	SharePoint ドキュメント ライブラリ	4	はい	はい
初期要求の最適化未対応のベースライン ソリューション	44	Web サービス	5	いいえ	はい	特別な検証ルールとして "過去の日付であること" があります。このルールでは、today() 関数が使用されるため、最初の要求で状態データが必要になります。
2x フィールド対応ベースライン ソリューション	88	Web サービス	4	はい	はい
3x フィールド対応ベースライン ソリューション	132	Web サービス	4	はい	はい
4x フィールド対応ベースライン ソリューション	176	Web サービス	4	はい	はい
検証対応ベースライン ソリューション	44	Web サービス	10	いいえ	はい
2x 検証対応ベースライン ソリューション	44	Web サービス	20	いいえ	はい
4x 検証対応ベースライン ソリューション	44	Web サービス	40	いいえ	はい

InfoPath リスト フォーム

案件管理リストの変更バージョンを使用して InfoPath リスト フォームの操作がテストされました。2 つの変更がリストに加えられました。1 番目の変更では、[担当者] 列が削除されました。2 番目の変更では、[関連する案件] 列が復数値を受け付けないように設定されました。最終的に、リストは、100 個の項目で事前にデータが生成されました。リストのスクリーン ショットを次に示します。

リスト フォーム

テストの定義

スケールアウト テスト

Web フロントエンドのスケールアウト テストで使用したテストの詳細を次の表に示します。

シナリオの説明	使用されているフォーム テンプレート	テストの手順	ポストバックの数
ベースライン ソリューション: 新規	ベースライン ソリューション	ベースライン ソリューションの新しいインスタンスを開きます。	0
新しいベースライン ソリューションの保存	ベースライン ソリューション	ベースライン ソリューションの新しいインスタンスを開きます。 フォームに入力し、フォームをドキュメント ライブラリに保存します。	1
ドキュメント ライブラリ送信対応ベースライン ソリューション	ドキュメント ライブラリ送信対応ベースライン ソリューション	ドキュメント ライブラリ送信対応ベースライン ソリューションの新しいインスタンスを開きます。 フォームに入力して [送信] をクリックします。これにより、フォームのデータが SharePoint ドキュメント ライブラリに送信されます。	1
Web サービス送信対応ベースライン ソリューション	Web サービス送信対応ベースライン ソリューション	Web サービス送信対応ベースライン ソリューションの新しいインスタンスを開きます。 フォームに入力して [送信] をクリックします。これにより、フォームのデータが Web サービスに送信されます。	1
ドキュメント ライブラリ送信対応ベースライン ソリューション x5	Web サービス送信フォーム テンプレート対応ベースライン ソリューションの 5 個のコピー。各コピーは独自のドキュメント ライブラリに展開されます。	各ドキュメント ライブラリで次の手順を実行します。 ドキュメント ライブラリ送信対応ベースライン ソリューションの新しいインスタンスを開きます。 フォームに入力して [送信] をクリックします。これにより、フォームのデータが SharePoint ドキュメント ライブラリに送信されます。	1
ベースライン ソリューション: 開く	ドキュメント ライブラリ送信対応ベースライン ソリューション	既に完了したベースライン ソリューション フォームを開きます。フォームは、ドキュメント ライブラリから開きます。	0

フォームの複雑さのテスト

フォームの複雑さのテストで使用したテストの詳細を次の表に示します。

テスト名	使用されているフォーム テンプレート	テストの手順	ポストバックの数
1x コントロール対応ベースライン ソリューション	Web サービス送信対応ベースライン ソリューション	Web サービス送信対応ベースライン ソリューションの新しいインスタンスを開きます。 フォームに入力して [送信] をクリックします。これにより、フォームのデータが Web サービスに送信されます。	1
2x コントロール対応ベースライン ソリューション	2x コントロール対応ベースライン ソリューション	2x コントロール対応ベースライン ソリューションの新しいインスタンスを開きます。 フォームに入力して [送信] をクリックします。これにより、フォームのデータが Web サービスに送信されます。	1
3x コントロール対応ベースライン ソリューション	3x コントロール対応ベースライン ソリューション	3x コントロール対応ベースライン ソリューションの新しいインスタンスを開きます。 フォームに入力して [送信] をクリックします。これにより、フォームのデータが Web サービスに送信されます。	1
4x コントロール対応ベースライン ソリューション	4x コントロール対応ベースライン ソリューション	4x コントロール対応ベースライン ソリューションの新しいインスタンスを開きます。 フォームに入力して [送信] をクリックします。これにより、フォームのデータが Web サービスに送信されます。	1
初期要求の最適化未対応のベースライン ソリューション	初期要求の最適化未対応のベースライン ソリューション	初期要求の最適化未対応のベースライン ソリューションの新しいインスタンスを開きます。 フォームに入力して [送信] をクリックします。これにより、フォームのデータが Web サービスに送信されます。	1
検証対応ベースライン ソリューション	検証対応ベースライン ソリューション	検証対応ベースライン ソリューションの新しいインスタンスを開きます。 フォームに入力して [送信] をクリックします。これにより、フォームのデータが Web サービスに送信されます。	1
2x 検証対応ベースライン ソリューション	2x 検証対応ベースライン ソリューション	2x 検証対応ベースライン ソリューションの新しいインスタンスを開きます。 フォームに入力して [送信] をクリックします。これにより、フォームのデータが Web サービスに送信されます。	1
4x 検証対応ベースライン ソリューション	4x 検証対応ベースライン ソリューション	4x 検証対応ベースライン ソリューションの新しいインスタンスを開きます。 フォームに入力して [送信] をクリックします。これにより、フォームのデータが Web サービスに送信されます。	1

InfoPath リスト フォームのテスト

InfoPath リスト フォームのテストで使用したテストの詳細を次の表に示します。

テスト名	テスト手順	ポストバックの数
案件管理: 表示	既存の案件管理リスト項目を表示ビューで開きます。	0
案件管理: 編集	既存の案件管理リスト項目を編集ビューで開きます。	0
案件管理: 新規	案件管理リストの新しい項目を開きます。	0

テスト結果

この記事で報告されているすべてのテストは、思考時間 (一連の操作間の自然遅延) なしで実行しました。現実の環境では、ユーザーがタスクの次のステップを実行するので、各操作の後に遅延が発生します。それに対して、これらのテストでは、各操作の後に次の操作を即座に実行して、ファームにロードをかけ続けました。このようなロードにより、データベース競合など、パフォーマンスに悪影響を及ぼす可能性がある要因が発生することもあります。

トポロジごとに、一連の 3 つのテストが実行されました。調整、グリーン ゾーン、最大スループットの 3 つです。調整稼働ではロード パターンのステップが使用されます。ロード パターンのステップでは、時間の経過と共に仮想ユーザーの数が増加します。調整稼働の結果、グリーン ゾーン テストと最大スループット テストのユーザー ロードが決まります。グリーン ゾーン テストと最大スループット テストでは、5 分間、一定のロード パターンが使用されます。このドキュメントに報告されている 1 秒あたりの要求数 (RPS) は、5 分間の一定のロード テストが終了した時点の平均 RPS です。

結果表の一部のセルにダッシュが含まれています。これは、そのトポロジでテストが実行されなかったことを示します。テストが実行されなかったのは、他のテストの実行結果によって、その特定のトポロジでは RPS の増加が予想されないことが示されたためです。

SharePoint Server 2010 の InfoPath Forms Services のボトルネックの詳細については、後の「一般的なボトルネックとその原因」を参照してください。

さまざまな送信操作に対する Web フロントエンドのスケールアウトの効果

次の表は、SharePoint Server 2010 におけるさまざまな送信操作に対してフロントエンド Web サーバーをスケールアウトした場合のグリーン ゾーン テストの結果を示しています。

	ベースライン ソリューション: 保存	Web サービス送信対応ベースライン ソリューション	SharePoint Server 2010 送信対応ベースライン ソリューション	5 個のドキュメントを使用する SharePoint Server 2010 送信対応ベースライン ソリューション
1x1	165	245	160	139
2x1	292	471	301	280
4x1	479	896	478	544
6x1	467	1395	-	599

次のグラフは、さまざまな Web フロントエンド トポロジでのさまざまな InfoPath 送信操作に対するグリーン ゾーンのスループットを示しています。SharePoint Server 2010 送信は、4 台のフロントエンド Web サーバーまで拡大できます。ただし、6 台のフロントエンド Web サーバーを備えて 5 つのドキュメント ライブラリ送信フォームを並行して実行するファームは、6 台のフロントエンド Web サーバーを備えて 1 つのドキュメント ライブラリ送信フォームを実行するファームよりも高いスループットを達成できます。通常、ファームには 1 つ以上の InfoPath ソリューションが展開されます。この結果は、それらの個々のソリューションの 1 つは 4 台のフロントエンド Web サーバーで最高のスループットに到達することを意味します。ただし、すべてのソリューションの集合的なスループットは、フロントエンド Web サーバーが 4 台を超えても拡大できます。スループットが最も高いのは Web サービスの送信であり、これは 6 台のフロントエンド Web サーバーまで拡大します。

送信操作のグリーン ゾーン スループット

次の表は、SharePoint Server 2010 におけるさまざまな送信操作に対してフロントエンド Web サーバーをスケールアウトした場合の最大テスト結果を示しています。

	ベースライン ソリューション: 保存	Web サービス送信対応ベースライン ソリューション	SharePoint Server 2010 送信対応ベースライン ソリューション	5 個のドキュメントを使用する SharePoint Server 2010 送信対応ベースライン ソリューション
1x1	286	470	301	285
2x1	484	912	464	518
4x1	-	1484	478	601
6x1	-	1483	-	-

次のグラフは、さまざまなフロントエンド トポロジでのさまざまな InfoPath 送信操作に対する最大スループットを示しています。SharePoint Server 2010 の送信と保存は、2 台のフロントエンド Web サーバーまで拡大します。ただし、4 台のフロントエンド Web サーバーを備えて 5 つのドキュメント ライブラリ送信フォームを並行して実行するファームは、4 台のフロントエンド Web サーバーを備えて 1 つのドキュメント ライブラリ送信フォームを実行するファームよりも高いスループットを達成できます。通常、ファームには 1 つ以上の InfoPath ソリューションが展開されます。この結果は、それらの個々のソリューションの 1 つは 4 台のフロントエンド Web サーバーで最高のスループットに到達することを意味します。ただし、すべてのソリューションの集合的なスループットは、フロントエンド Web サーバーが 4 台を超えても拡大できます。スループットが最も高いのは Web サービスの送信であり、これは 4 台のフロントエンド Web サーバーまで拡大します。

送信操作の最大スループット

さまざまな InfoPath リスト操作に対するフロントエンド Web サーバーのスケールアウトの効果

次の表は、SharePoint Server 2010 における InfoPath リスト操作に対してフロントエンド Web サーバーを追加した場合のグリーン ゾーン テストの結果を示しています。

	案件管理: 表示	案件管理: 新規	案件管理: 編集
1x1	77	67	56
2x1	153	125	106
4x1	295	236	212
6x1	455	431	416

次のグラフは、InfoPath リスト操作のグリーン ゾーン スループットを示しています。すべての操作は、フロントエンド Web サーバーを追加することでスループットが向上することを示しています。また、結果は、6 台を超えるフロントエンド Web サーバーを追加してもスループットは向上を続けることも示しています。この向上は、容量計画テストの範囲外で確認されました。表示操作は新規操作よりも高いスループットを示し、新規操作は編集操作よりも高いスループットを示しています。

リスト操作のグリーン ゾーン スループット

次の表は、SharePoint Server 2010 における InfoPath リスト操作に対してフロントエンド Web サーバーを追加した場合の最大スループット テストの結果を示しています。

	案件管理: 表示	案件管理: 新規	案件管理: 編集
1x1	143	126	100
2x1	263	243	191
4x1	524	457	364
6x1	747	679	521

次のグラフは、InfoPath リスト操作の最大スループットを示しています。すべての操作は、フロントエンド Web サーバーを追加することでスループットが向上することを示しています。また、結果は、6 台を超えるフロントエンド Web サーバーを追加してもスループットは向上を続けることも示しています。この向上は、容量計画テストの範囲外で確認されました。表示操作は新規操作よりも高いスループットを示し、新規操作は編集操作よりも高いスループットを示しています。

リスト操作の最大スループット

新規および開く操作に対する Web フロントエンドのスケールアウトの効果

次の表は、SharePoint Server 2010 における InfoPath の新規および開く操作に対してフロントエンド Web サーバーを追加した場合のテスト結果を示しています。

	案件管理: 新規	案件管理: 表示	ベースライン ソリューション: 新規	ベースライン ソリューション: 開く
1x1	67	77	197	129
2x1	125	153	379	296
4x1	236	295	802	575
6x1	431	455	1182	869

次のグラフは、InfoPath の新規および開く操作のグリーン ゾーン スループットを示しています。すべての操作は、フロントエンド Web サーバーを追加することでスループットが向上することを示しています。結果は、6 台を超えるフロントエンド Web サーバーを追加してもスループットは向上を続けることを示しています。この向上は、容量計画テストの範囲外で確認されました。ドキュメント ライブラリの新規および開く操作は、InfoPath リストの新規および表示操作よりも高いスループットを示しています。

新規および開く操作のグリーン ゾーン スループット

	案件管理: 新規	案件管理: 表示	ベースライン ソリューション: 新規	ベースライン ソリューション: 開く
1x1	126	143	408	282
2x1	243	263	775	558
4x1	457	524	1285	996
6x1	679	747	1360	1104

次のグラフは、InfoPath リスト操作の最大スループットを示しています。すべての操作は、フロントエンド Web サーバーを追加することでスループットが向上することを示しています。結果は、ドキュメント ライブラリの新規および開く操作の場合 6 台のフロントエンド Web サーバーまで拡大することを示しています。ただし、結果は、InfoPath リスト操作は 6 台を超えるフロントエンド Web サーバーからメリットが得られた可能性があることを示しています。ドキュメント ライブラリの新規および開く操作は、InfoPath リストの新規および表示操作よりも高いスループットを示しています。

新規および開く操作の最大スループット

フォームの複雑さがスループットに与える影響

次の表は、フォーム コントロールをフォーム テンプレートに追加した場合のテスト結果を示しています。結果はすべて、4 台のフロントエンド Web サーバーが含まれるファーム トポロジで収集しました。

	1x コントロール対応ベースライン ソリューション	2x コントロール対応ベースライン ソリューション	3x コントロール対応ベースライン ソリューション	4x コントロール対応ベースライン ソリューション
最大スループット	1484	1424	1310	1201
グリーン ゾーン	896	834	760	608

次のグラフは、フォーム コントロールをフォーム テンプレートに追加した場合のテスト結果を示しています。フォーム内のフィールドとコントロールの数は、スループットに多大な影響を与えます。これらの結果は、コントロールの数が 4 倍になると、グリーン ゾーンのスループットが 30% 以上減少する可能性があることを示しています。

コントロール数のスループットへの影響

次の表は、フォーム コントロールをフォーム テンプレートに追加した場合のテスト結果を示しています。結果はすべて、4 台のフロントエンド Web サーバーが含まれるファーム トポロジで収集しました。

	ベースライン ソリューション	初期要求の最適化未対応のベースライン ソリューション	検証対応ベースライン ソリューション	2x 検証対応ベースライン ソリューション	4x 検証対応ベースライン ソリューション
最大スループット	1484	1323	1271	1202	1074
グリーン ゾーン	896	788	724	676	612

次のグラフは、検証ルールをフォーム テンプレートに追加した場合のテスト結果を示しています。フォーム内の検証ルールの数は、スループットに測定可能な影響を与えます。これらの結果は、検証ルールの数が 4 倍になると、グリーン ゾーンのスループットが 30% 以上減少する可能性があることを示しています。

検証ルール数のスループットへの影響

トランザクションあたりのハードウェア コスト

案件管理の表示操作の最大 RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	91.5%	85.8%	85.8%	81.1%
信頼性	平均ページ時間	0.088	0.093	0.11	0.098
	失敗率	0%	0%	0%	0%

ベースライン ソリューションの新規操作のグリーン ゾーン RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	44.1%	43.7%	46.5%	46.5%
信頼性	平均ページ時間	0.024	0.025	0.027	0.033
	失敗率	0%	0%	0%	0%

ベースライン ソリューションの新規操作の最大 RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	93.7%	91.1%	77.5%	54.0%
信頼性	平均ページ時間	0.048	0.050	0.052	0.056
	失敗率	0%	0%	0%	0%

ベースライン ソリューションの保存操作のグリーン ゾーン RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	40.8%	41.3%	37.3%	24.2%
信頼性	平均ページ時間	0.059	0.074	0.099	0.10
	失敗率	0%	0.21%	0.0014%	0%

ベースライン ソリューションの保存操作の最大 RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	85.8%	76.8%	-	-
信頼性	平均ページ時間	0.090	0.12	-	-
	失敗率	0%	0.18%	-	-

ベースライン ソリューションのドキュメント ライブラリ送信操作のグリーン ゾーン RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	40.6%	44.9%	35.9%	-
信頼性	平均ページ時間	0.061	0.079	0.11	-
	失敗率	0%	0%	0%	-

ベースライン ソリューションのドキュメント ライブラリ送信操作の最大 RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	89.1%	74.8%	-	-
信頼性	平均ページ時間	0.11	0.12	-	-
	失敗率	0.0022%	0%	-	-

Web サービス送信操作対応ベースライン ソリューションのグリーン ゾーン RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	45.0%	44.0%	43.8%	46.0%
信頼性	平均ページ時間	0.040	0.042	0.046	0.059
	失敗率	0%	0%	0.00074%	0%

Web サービス送信操作対応ベースライン ソリューションの最大 RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	91.8%	91.4%	74.6%	48.9%
信頼性	平均ページ時間	0.076	0.080	0.091	0.11
	失敗率	0%	0%	0%	0%

5 回のドキュメント ライブラリ送信操作対応ベースライン ソリューションのグリーン ゾーン RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	38.4%	39.8%	40.8%	-
信頼性	平均ページ時間	0.070	0.077	0.10	-
	失敗率	0%	0%	0%	-

ドキュメント ライブラリと 5 回の送信操作対応ベースライン ソリューションの最大 RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	88.4%	80.5%	44.3%	29.7%
信頼性	平均ページ時間	0.12	0.16	0.12	0.12
	失敗率	0%	0%	0.000011%	0%

ベースライン ソリューションの開く操作のグリーン ゾーン RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	39.2%	45.8%	45.5%	46.2%
信頼性	平均ページ時間	0.036	0.038	0.041	0.049
	失敗率	0%	0%	0%	0%

ベースライン ソリューションの開く操作の最大 RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	90.6%	90.6%	82.1%	60.0%
信頼性	平均ページ時間	0.063	0.067	0.069	0.084
	失敗率	0%	0%	0%	0%

案件管理の表示操作のグリーン ゾーン RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	44.8%	45.4%	44.6%	46.4%
信頼性	平均ページ時間	0.061	0.067	0.073	0.072
	失敗率	0%	0%	0%	0%

案件管理の表示操作の最大 RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	91.5%	85.8%	85.8%	81.1%
信頼性	平均ページ時間	0.088	0.093	0.11	0.098
	失敗率	0%	0%	0%	0%

案件管理の編集操作のグリーン ゾーン RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	45.7%	43.6%	45.1%	60.0%
信頼性	平均ページ時間	0.086	0.090	0.10	0.11
	失敗率	0%	0%	0%	0%

案件管理の表示操作のグリーン ゾーン RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	89.8%	87.2%	82.9%	79.3%
信頼性	平均ページ時間	0.12	0.13	0.13	0.14
	失敗率	0%	0%	0.00092%	0.012%

案件管理の表示操作の最大 RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	91.5%	85.8%	85.8%	81.1%
信頼性	平均ページ時間	0.088	0.093	0.11	0.098
	失敗率	0%	0%	0%	0%

案件管理の新規操作のグリーン ゾーン RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	44.8%	42.9%	40.9%	50.5%
信頼性	平均ページ時間	0.072	0.076	0.089	0.097
	失敗率	0%	0%	0%	0%

案件管理の新規操作の最大 RPS

スコアカード ダッシュボード	スコアカード測定基準	1x1	2x1	4x1	6x1
CPU	平均フロントエンド Web サーバー CPU	92.6%	89.2%	85.1%	84.9%
信頼性	平均ページ時間	0.12	0.12	0.12	0.14
	失敗率	0%	0%	0%	0%

コントロール対応ベースライン ソリューションのグリーン ゾーン RPS

スコアカード ダッシュボード	スコアカード測定基準	1x	2xControls	3xControls	4xControls
CPU	平均フロントエンド Web サーバー CPU		43.9%	49.8%
信頼性	平均ページ時間		0.050	0.054
	失敗率		0%	0%

コントロール対応ベースライン ソリューションの最大 RPS

スコアカード ダッシュボード	スコアカード測定基準	1x	2xControls	3xControls	4xControls
CPU	平均フロントエンド Web サーバー CPU		79.2%	80.9%	80.2%
信頼性	平均ページ時間		0.098	0.12	0.12
	失敗率		0%	0%	0.00056%

ベースライン ソリューションの検証操作のグリーン ゾーン RPS

スコアカード ダッシュボード	スコアカード測定基準	初期要求の最適化が行われない	1xValidation	2xValidation	4xValidation
CPU	平均フロントエンド Web サーバー CPU	45.4%	44.7%	45.5%	46.3%
信頼性	平均ページ時間	0.055	0.057	0.061	0.068
	失敗率	0%	0%	0.19%	0%

ベースライン ソリューションの検証操作の最大 RPS

スコアカード ダッシュボード	スコアカード測定基準	初期要求の最適化が行われない	1xValidation	2xValidation	4xValidation
CPU	平均フロントエンド Web サーバー CPU	80.4%	82.4%	86.8%	85.2%
信頼性	平均ページ時間	0.10	0.11	0.13	0.11
	失敗率	0.0015%	0%	0%	0.00055%

推奨事項

ここでは、パフォーマンスおよび容量に関する全般的な推奨事項を説明します。これらの推奨事項から、作成した開始トポロジの容量およびパフォーマンスの特性を確認して、開始トポロジのスケール アウトとスケール アップのどちらが必要かを判断することができます。

ハードウェアに関する推奨事項

システムの最小要件と推奨要件の詳細については、「ハードウェア要件およびソフトウェア要件 (SharePoint Server 2010)」を参照してください。

スケール アップ トポロジとスケール アウト トポロジ

開始点トポロジの容量を増やし、パフォーマンスを向上させるには、既存のサーバー コンピューターの容量を増やしてスケール アップするか、追加のサーバーをトポロジに追加してスケール アウトすることができます。このセクションでは、複数のスケール アウト トポロジの一般的なパフォーマンス特性について説明します。サンプル トポロジでは、次の一般的な方法によって InfoPath Forms Services シナリオのトポロジをスケール アウトします。

• ユーザー ロードの増加に対応するには、Web サーバー コンピューターを追加します。

• データ ロードの増加に対応するには、1 つの (クラスター化またはミラー化された) サーバーの容量を増加するか、64 ビット サーバーにアップグレードするか、クラスター化またはミラー化されたサーバーを追加することで、容量をデータ サーバー ロールに追加します。

• 1 台の (クラスター化またはミラー化された) データベース サーバー コンピューターに対して Web サーバー コンピューターが 8 台を超えないような比率を維持します。ラボでのテストでは、テスト シナリオごとに、データベース サーバーに対する Web サーバーの特定の最適比が得られましたが、特にデータベース サーバーに対して、より強固なハードウェアを展開することで環境においてより良い結果が得られる場合があります。

スループット目標の見積もり

多くの要因がスループットに影響する可能性があります。これらの各要因はファームのスループットに大きい影響を与える可能性があります。展開を計画する場合は、これらの各要因について慎重に検討する必要があります。このような要因には、次のものがあります。

• ユーザー数

• ユーザー操作の種類、複雑さ、および頻度

• 操作内のポストバック数

• データ接続のパフォーマンス

SharePoint Server 2010 はさまざまな方法で展開および構成できます。そのため、特定の数のサーバーでどの程度のユーザー数をサポートできるかを簡単に見積もる方法はありません。したがって、SharePoint Server 2010 を運用環境に展開する前に必ず独自の環境でテストを実施してください。

最適化

以下のセクションでは、フォーム テンプレートとデータベース サーバーを最適化することで、ファームのパフォーマンスを向上する方法について説明します。

フォーム テンプレート設計の最適化

• onLoad イベントまたはビジネス ロジックを含まないフォーム テンプレート用に最初の要求 (つまり、フォームを開く要求) を最適化します。データベースへのセッション状態エントリの作成を POST が発生するまで遅延することで、最初の要求を最適化します。このようなフォーム テンプレートでは、唯一の POST が送信操作後のフォームを閉じることであった場合、SQL セッション状態は作成されません。この最適化を適用するには、フォーム設計者は、Submit の詳細設定を、送信操作後にフォームを閉じるように設定する必要があります。フォーム テンプレート設計の最適化の詳細については、6 回シリーズのブログ「Designing browser-enabled forms for performance in InfoPath Forms Services (英語)」(https://go.microsoft.com/fwlink/?linkid=129548&clcid=0x411) (英語) を参照してください。

• ドキュメント ライブラリへのフォームの保存がシナリオに含まれる場合、フォームを保存するのではなく、フォームをライブラリに送信することをお勧めします。送信操作では 1 つの POST 要求またはラウンド トリップのみが起動されるのに対して、保存操作では 2 つの POST 要求が起動されます。フォームの名前は、ルールを使用するかフォーム内でコントロールを使用することで、動的に生成できます。

• ドキュメント ライブラリのフォームでは、InfoPath リスト フォームよりも高いスループットを達成できます。ソリューションで高いスループットが必要な場合、InfoPath リスト フォームの代わりにドキュメント ライブラリのフォームを使用することを検討してください。

• コントロールの数、フォームのロジックの量のようなフォームの複雑さはスループットに影響を与えます。フォームの複雑さが増すと、フロントエンド Web サーバーの CPU コストも増加します。したがって、フォームをより複雑にするには、フロントエンド Web サーバーを増加してスループットを高める必要があります。

• ユーザーの待機時間を短縮するには、フォーム設計者が 1 ビューあたりのコントロール数を削減することをお勧めします。1 ページ目のビューを最適化するには、リソース コストの高いコントロール (リッチ テキスト フィールドなど) を既定のビューではなく後続のビューに配置します。

一般的なボトルネックとその原因

パフォーマンスのテスト中、一般的なさまざまなボトルネックがいくつかわかってきました。ボトルネックとは、特定のファーム構成の容量が限界に達している状態です。これによりファームのスループットが停滞または低下します。

次の表で、いくつかの一般的なボトルネックを示し、その原因と、考えられる解決方法について説明します。

パフォーマンスとスケーラビリティのトラブルシューティング

ボトルネック	原因	解決方法
データベース競合 (ロック)	データベース ロックは、複数のユーザーが特定のデータのセットに対して競合する変更を加えることを禁止します。データのセットがユーザーまたはプロセスによってロックされている場合、そのユーザーまたはプロセスがデータの変更を終了し、ロックを解除するまで、他のユーザーまたはプロセスはその同じデータのセットを変更することはできません。	データベース ロックの発生を減らすには、次の方法があります。 送信されるフォームをより多くのドキュメント ライブラリに分散します。 データベース サーバーをスケール アップします。 データベース サーバーのハード ディスクを読み取り/書き込みに最適化します。 NOLOCK パラメーターなど、Microsoft SQL Server 2005 にはデータベース ロックを回避する方法があります。ただし、データが破損する可能性があるため、この方法の使用は非推奨またはサポート対象外です。
データベース サーバーのディスク I/O	ハード ディスクに対する I/O 要求の数がディスクの I/O 容量を超えると、要求はキューに入れられます。その結果、各要求が完了するまでの時間が増加します。	複数の物理ドライブにデータ ファイルを分散すると、並列 I/O が可能になります。ディスク I/O に関する問題の解決に役立つ情報については、ブログ「SharePoint Disk Allocation and Disk I/O (英語)」(https://go.microsoft.com/fwlink/?linkid=129557&clcid=0x411) (英語) を参照してください。
Web サーバー CPU 使用率	Web サーバーがユーザー要求でオーバーロードになると、平均 CPU 使用率が 100% 近くになります。これにより、Web サーバーが要求にすぐに応答できなくなり、タイムアウトが発生してクライアント コンピューターにエラー メッセージが表示される場合があります。	この問題を解決する方法は 2 つあります。1 つは、Web サーバーをファームに追加してユーザー ロードを分散する方法で、もう 1 つは、より高速なプロセッサを追加して Web サーバーをスケール アップする方法です。

パフォーマンスの監視

システムをスケール アップまたはスケール アウトするタイミングを判断するには、パフォーマンス カウンターを使用してシステムの正常性を監視します。次の表の情報を使用して、監視するパフォーマンス カウンターと、そのパフォーマンス カウンターが適用されるプロセスを判断します。

Web サーバー

次の表は、ファーム内の Web サーバーを監視するためのパフォーマンス カウンターおよびプロセスを示しています。

パフォーマンス カウンター	対象のオブジェクト	メモ
プロセッサ時間	合計	このスレッドが手順を実行するためにプロセッサを使用した経過時間の比率を表します。
メモリ使用率	アプリケーション プール	アプリケーション プールのシステム メモリの平均使用率を表します。監視する適切なアプリケーション プールを特定する必要があります。 基本的なガイドラインとして、特定の Web アプリケーションの最大メモリ使用率を特定し、その数に 10 を加えた値を、関連付けられているアプリケーション プールに割り当てます。

データベース サーバー

次の表に、ファーム内のデータベース サーバーを監視するためのパフォーマンス カウンターおよびプロセスを示します。

パフォーマンス カウンター	対象のオブジェクト	メモ
平均ディスク キュー長	SharedServices.mdf を格納するハード ディスク	平均値が 1.5/スピンドルを上回っている場合はハード ディスクの書き込み速度が不十分です。
プロセッサ時間	SQL Server プロセス	平均値が 80% を上回っている場合はデータベース サーバーのプロセッサ容量が不十分です。
プロセッサ時間	合計	このスレッドが手順を実行するためにプロセッサを使用した経過時間の比率を表します。
メモリ使用率	合計	システム メモリの平均使用率を表します。

See Also

Other Resources

InfoPath Forms Services 2010 Web Testing Toolkit (英語)