InfoPath Forms Services 環境のパフォーマンスと容量の要件を予測する (Office SharePoint Server)

  • [アーティクル]

この記事の内容 :

  • 主要特性

  • テスト環境

  • テスト結果

  • 推奨事項

このパフォーマンスおよび容量の計画のシナリオでは、InfoPath Forms Services を実行する単一の Microsoft Office SharePoint Server 2007 ファームが使用されています。このファームは、InfoPath フォーム テンプレートの発行に使用されます。この記事に表示されるテスト結果は Office SharePoint Server 2007 の InfoPath Forms Services 特有のものです。テスト結果が、Microsoft Office Forms Server 2007 のパフォーマンス特性を表さない場合もあります。

主要特性

主要特性とは、このシナリオに基づく展開で予測される環境要因、使用特性、および他の考慮事項を指します。

このシナリオの主要特性は次のとおりです。

  • **認証、アクセス制御、およびアクセス許可   **このシナリオでは、統合 Windows 認証を使用します。通常は、セキュリティ グループを使用するか、ユーザー アカウントに基づいて個々のユーザーにアクセス権を付与することで、サイトとコンテンツの保護が行われます。認証やアクセス許可はスループットに影響を及ぼします。また、これらを行うにはファーム サーバーとドメイン コントローラ間のネットワーク接続が必要になります。スループットは、サーバー ファームが 1 秒あたりに実行できる操作の数を表します。スループットの測定単位は、秒あたりの要求 (RPS) です。

  • 関連付けられたディレクトリ サービス   このシナリオには、ユーザーや組織の情報を提供するため、関連付けられた Active Directory ディレクトリ サービスが組み込まれています。この情報は Office SharePoint Server 2007 の機能によって使用され、プレゼンス、配信、対象ユーザーの設定などの高度な機能が実現されます。

  • 複雑な (読み取り/書き込み) ユーザー操作   フォーム環境では、ユーザーによってコンテンツの表示や投稿が行われます。このシナリオのスループット目標は、フォーム テンプレートのアップロード、フォームへの記入など、複雑なユーザー操作に対する応答時間を妥当な範囲にとどめるためのものです。

  • 時間の経過に伴うデータの増大とサイトの成長   Office SharePoint Server 2007 グループ作業環境は、初期のデータ量を予測したうえで、時間の経過に伴うデータの増大やサイトの成長にも対応できるようにする必要があります。初期のデータ量に基づいて設計したサーバー ファームは、すぐに容量不足になる可能性があります。

  • ユーザー応答時間   各種操作 (一般的な操作、一般的でない操作、長時間の操作、まれにしか実行されない操作) の目標ユーザー応答時間は、「ソフトウェア境界を計画する (Office SharePoint Server)」セクションの末尾にある表**「ユーザーの応答時間」**に記載されています。ユーザー応答時間の許容範囲は組織によって異なります。予想されるユーザー応答時間は、全体的なスループット目標を左右する重要な要素です。ユーザーの数が増えれば増えるほど、同じユーザー応答時間を実現するために目標スループットを上げる必要があります。

  • ユーザー同時性   同時実行率は 10% で、常にユーザーの 1% が同時に要求を行うと仮定しています。たとえば、10,000 ユーザーの場合、1,000 ユーザーがソリューションを同時に使用し、100 ユーザーが要求を行っていることになります。

テスト環境

このシナリオのテストは、次の要素の変化により、さまざまなファーム構成がどのような影響を受けるのかを予測できるようにするためのものです。

  • フォームの複雑さ

  • ユーザー操作の種類

  • データ接続の種類

  • フォームの送信先ドキュメント ライブラリの数

この記事に示している特定の容量やパフォーマンスの値は実際の環境の値とは異なることを理解してください。ここで示す値は、適切な規模の環境を設計するための基礎となるものです。最初のシステム設計が終了したら、実際の環境におけるさまざまな要素にシステムが対応できるかどうかを判断するために構成をテストします。

展開のテスト方法の詳細については、「パフォーマンスと容量を計画するためのツール (Office SharePoint Server)」および「InfoPath Forms Services 2007 Web Testing Toolkit (英語)」(https://go.microsoft.com/fwlink/?linkid=129547&clcid=0x411) を参照してください。

前提

  • 64 ビット アーキテクチャ   このテスト環境では、64 ビットの Web サーバーだけが使用されています。Office SharePoint Server 2007 は 32 ビット サーバー上でも展開できますが、ファームを展開する場合は 64 ビット サーバーを採用することをお勧めします。 詳細については、記事「パフォーマンスと容量の計画について (Office SharePoint Server)」の「64 ビット版と 32 ビット版」セクションを参照してください。

テスト定義

ここでは、テストのシナリオを定義し、各シナリオで使用されたテスト プロセスの概要を説明します。テスト結果や各パラメータといった詳細情報は、この記事の後半の各テスト結果のセクションで示します。

テスト定義

ソリューション名 テストの説明

ベースライン ソリューション

  1. 送信 Web サービス データ接続を使用してベースライン フォームを開きます。

  2. フォームにテスト データを記入します。

  3. 自動終了を使用して、フォームを送信します。

フォームを開く

  • データ接続を使用せずにベースライン フォームを開きます。

単一 SharePoint ドキュメント ライブラリに保存します。

  1. データ接続を使用せずにベースライン フォームを開きます。

  2. フォームにテスト データを記入します。

  3. SharePoint ドキュメント ライブラリに保存します。

SharePoint データ接続を介してフォームを送信する

  1. SharePoint 送信データ接続を使用してベースライン フォームを開きます。

  2. フォームにテスト データを記入します。

  3. 自動終了を使用して、フォームを送信します。

ビジネス ロジックと複雑なコントロールを追加したベースライン ソリューション

  1. 送信 Web サービス データ接続を使用して complex passport simple フォームを開きます。

  2. フォームにテスト データを記入します。

  3. 自動終了を使用して、フォームを送信します。

SharePoint データ接続を介してフォームを保存します (5 つのドキュメント ライブラリ)。

  1. データ接続を使用せずに 5 つのうち 1 つのベースライン フォームを開きます。

  2. フォームにテスト データを記入します。

  3. [保存] をクリックします。

SharePoint データ接続を介してフォームを送信する (5 つのドキュメント ライブラリ)

  1. SharePoint 送信データ接続を使用して 5 つのベースライン フォームのうち 1 つを開きます。

  2. フォームにテスト データを記入します。

  3. 自動終了を使用して、フォームを送信します。

ラボ トポロジ

詳しいテスト結果を提供するために、いくつかのファーム構成がテストに使用されました。ファーム構成は、1 ～ 8 台の Web サーバーおよび Microsoft SQL Server 2005 データベース ソフトウェアを実行する 1 台のデータベース サーバー コンピュータです。テストは、4 台のクライアント コンピュータで実行されました。すべての Web サーバー コンピュータとデータベース サーバーは 64 ビット、クライアント コンピュータは 32 ビットでした。

次の表に、テストに使用した具体的なハードウェアを示します。

コンピュータの役割 ハードウェア

Web サーバー

2 つのクアッドコア Intel Xeon E5345 2.33 ギガヘルツ (GHz) プロセッサ

8 ギガバイト (GB) の RAM

データベース サーバー

4 つのクアッドコア Intel Xeon 3.2 GHz プロセッサ

16 GB の RAM

5 つの 146-GB 15,000-RPM ハード ディスク、RAID 5

クライアント コンピュータ

2 つの Intel 3.06-GHz プロセッサ

2 GB の RAM

このテスト環境では、ギガビット (1,000,000,000 bps) ネットワークを使用しました。ネットワークが使用されました。十分なネットワーク帯域幅を確保するために、Office SharePoint Server ファーム内のサーバー間ではギガビット ネットワークを使用することをお勧めします。

ソフトウェア

次の表に、このテストに使用したサーバーにインストールされていたソフトウェアを示します。

コンピュータの役割 ソフトウェア

Web サーバー

Windows Server 2008 Enterprise Edition Service Pack 1 (SP1) オペレーティング システム (最新の更新プログラムを適用済み)

Microsoft Office SharePoint Server 2007 Service Pack 1 (SP1)、x64 バージョン

テストは Microsoft Office Servers インフラストラクチャ更新プログラム のリリースよりも前に行われたことに注意してください。

Microsoft .NET Framework 3.5

データベース サーバー

Windows Server 2008 Enterprise Edition SP 1 (最新の更新プログラムを適用済み)

SQL Server 2005 データベース ソフトウェア

.NET Framework 3.5

クライアント コンピュータ

Windows Server 2003 Enterprise Edition SP 1 (最新の更新プログラムを適用済み)

テスト結果

次の表に、Office SharePoint Server 2007 SP1 上の InfoPath Forms Services についてのテスト結果を示します。ファームのパフォーマンスに対する影響を段階的に示すため、各テスト グループでは特定の要素だけが変更されています。

この記事で説明するすべてのテストは、考えるための時間や自然に発生する操作の間の時間を置かずに実行されました。実際の環境では、各操作の間には、ユーザーがタスクの次の手順を実行するために時間が空きます。対照的にこのテストでは、操作がすぐに連続して実行されているため、ファームに負荷が継続してかかっています。この負荷のために、パフォーマンスに悪影響を及ぼす可能性があるデータベースの競合やその他の要因が生成されています。

InfoPath Forms Services のボトルネックの詳細については、この記事の後半の「一般的なボトルネックとその原因」セクションを参照してください。

フォームのビジネス ロジックと複雑なコントロールがスループットに及ぼす影響

次の表の 2 つのテストは、フォームにビジネス ロジックと複雑なコントロールを追加したときに、ファームのスループットにどのような影響を及ぼすかを示します。テストしたフォーム テンプレートの違いは、このセクションの最後の表に示します。

Web サーバー ベースライン ソリューションのパフォーマンス (RPS) ビジネス ロジックと複雑なコントロールを追加したベースライン ソリューションのパフォーマンス (RPS)

1

325

292

2

633

547

4

1076

954

6

1052

1095

8

1102

1065

次のグラフからは、ビジネス ロジックや複雑なコントロールを追加しても、ファームのスループットが直線的には低下していないことがわかります。どちらのテスト ソリューションでも、4 台の Web サーバーを使用したときにスループットが大きく向上します。どちらのテスト ソリューションも傾向は似ています。つまり、ビジネス ロジックと複雑なコントロールをフォームで使用すると、ファームの Web サーバーに対する要求が高まり、場合によってはファームに Web サーバーの追加が必要になることもあります。

ビジネス ロジックの影響のグラフ

次の表に、複雑なフォーム ソリューションのためのフォーム テンプレート設計の変数を示します。

フォーム テンプレート変数

パラメータ ベースライン ソリューション ビジネス ロジックと複雑なコントロールを追加したベースライン ソリューション

ボトルネック

データベース ディスク I/O

データベース ディスク I/O

データ接続

1 (Web サービスへの送信)

1 (Web サービスへの送信)

メイン データ ソース

平面 (すべての要素が myFields の直接の子)

階層 (要素がセクションにグループ化されている)

送信時クローズ ルール

○

○

セクション

0

6 (2 つはオプション)

繰り返しテーブル

0

1

データ検証

4

10

ルール

0

3

ポストバック

2

1

最初の要求の最適化

○

×

さまざまな操作がスループットに及ぼす影響

これらのテストでは、特定のソリューションに対して各種操作が行われると、ファームのスループットにどのような影響があるのかについて明らかにします。

次の表に、同じフォームに対して各種操作 (Web サービスへの送信、フォームのオープン、単一ドキュメント ライブラリへの保存、SharePoint データ接続への送信) が行われた際のスループットの違いを示します。

すべてのポストバックは 10 KB です。

さまざまな操作がスループットに及ぼす影響

Web サーバー ベースライン ソリューション (Web サービスへの送信) (RPS) フォームのオープン (RPS) 単一のドキュメント ライブラリに保存する (RPS) SharePoint データ接続への送信 (RPS)

1

325

302

331

241

2

633

591

416

313

4

1076

847

429

301

6

1052

877

426

292

8

1102

825

431

305

次のグラフからわかるように、単一ドキュメント ライブラリに対する保存操作や SharePoint データ接続への送信操作はスループットに大きな影響を及ぼしています。ファームに Web サーバーを追加してもスループットは改善されていません。ただし、Web サーバーの追加により、Web サービスへの送信操作やフォームのオープン操作のパフォーマンスは向上しています。

このテスト シナリオでは、最高のパフォーマンスは 4 台の Web サーバーの使用により実現しました。より高性能のデータベース サーバーを使用すると結果が向上する可能性があります。また、セッション状態データベースとは別のデータベース サーバーにコンテンツ データベースを置いてもよいでしょう。この方法により、テスト ラボではファームのパフォーマンスが少なくとも 10% 向上しました。

InfoPath Form Server 操作の影響のグラフ

次の表に、このテスト シナリオで使用したフォーム テンプレート設計のパラメータを示します。

フォーム テンプレート変数

パラメータ ベースライン ソリューション フォームを開く 単一ドキュメント ライブラリへの保存 SharePoint データ接続への送信

ボトルネック

データベース ディスク I/O

該当なし

データベースのロック

データベースのロック

データ接続

1 (Web サービスへの送信)

1 (SharePoint ドキュメント ライブラリへの送信)

1 (Web サービスへの送信)

1 (SharePoint データ接続への送信)

メイン データ ソース

フラット (すべての要素はマイフィールドの直接の子)

フラット

フラット

フラット

送信時クローズ ルール

○

○

×

○

セクション

0

0

0

0

繰り返しテーブル

0

0

0

0

データ検証

4

4

4

4

ルール

0

0

0

0

ポストバック

2

1

2

1

最初の要求の最適化

○

×

○

×

単一のドキュメント ライブラリと複数のドキュメント ライブラリのスループットへの影響

次の表のテストは、単一ドキュメント ライブラリにフォームを送信する場合とフォーム送信を複数ドキュメント ライブラリに分散する場合のスループットに対する影響を示します。

単一のドキュメント ライブラリと複数のドキュメント ライブラリのスループットへの影響

Web サーバー ベースライン (RPS) SharePoint データ接続を介した単一ドキュメント ライブラリへの送信 (RPS) SharePoint データ接続を介した 5 つのドキュメント ライブラリへの送信 (RPS) 単一のドキュメント ライブラリに保存する (RPS) 5 つのドキュメント ライブラリに保存する (RPS)

1

325

241

229

331

319

2

633

313

436

416

523

4

1076

301

485

429

637

6

1052

292

455

426

591

8

1102

305

468

431

621

次のグラフからわかるように、複数のドキュメント ライブラリにフォームを分散するとパフォーマンスに好影響があります。小規模の展開では、複数ドキュメント ライブラリの使用は特に考慮すべき要素ではありませんが、単一ドキュメント ライブラリに保存されるフォーム数が「ソフトウェア境界を計画する (Office SharePoint Server)」で説明する制限を超えると、分散ドキュメント ライブラリを使用することにより競合が減少しパフォーマンスが大幅に向上します。大規模企業向け展開では、ドキュメント ライブラリに保存されるフォームではなく、データ接続を介してデータを送信するフォームを設計することをお勧めします。

InfoPath Forms Server のデータ接続の影響

次の表に、このテストで使用したフォーム テンプレート設計のパラメータを示します。

フォーム テンプレート変数

パラメータ SharePoint データ接続を介してフォームを送信する SharePoint データ接続を介してフォームを送信する (5 つのドキュメント ライブラリ) 単一のドキュメント ライブラリに保存する (RPS) 5 つのドキュメント ライブラリに保存する (RPS)

ボトルネック

データベースのロック

データベースのロック

データベースのロック

データベースのロック

データ接続

1 (SharePoint ドキュメント ライブラリへの送信)

1 (Web サービスへの送信)

1 (SharePoint ドキュメント ライブラリへの送信)

1 (Web サービスへの送信)

メイン データ ソース

フラット (すべての要素はマイフィールドの直接の子)

フラット

フラット

フラット

送信時クローズ ルール

○

○

○

○

セクション

0

0

0

0

繰り返しテーブル

0

0

0

0

データ検証

4

4

4

4

ルール

0

0

0

0

ポストバック

1

1

1

1

最初の要求の最適化

×

×

×

×

推奨事項

ここでは、パフォーマンスと容量に関する一般的な推奨事項について説明します。これらの推奨事項を参照し、「可用性を計画する (Office SharePoint Server)」を基に作成した開始トポロジの容量とパフォーマンスの特性を把握してください。また、開始トポロジをスケール アウトまたはスケール アップする必要があるかどうかも確認してください。

ハードウェア推奨事項

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

注意

Web サーバーとデータベース サーバーのメモリの要件は、ファームのサイズ、同時実行ユーザーの数、およびファームにおける機能やページの複雑さによって変わります。次の表に示すメモリについての推奨事項は、小規模なファームや利用の少ないファームには十分ですが、メモリの使用状況は慎重に監視し、メモリを追加する必要があるかどうかを見極める必要があります。

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

「可用性を計画する (Office SharePoint Server)」で説明されている開始点トポロジと各自のトポロジを比較することで、各自の開始点トポロジのパフォーマンスを予測できます。この作業を行えば、パフォーマンスや容量の目標に合わせて開始点トポロジをスケール アップまたはスケール アウトする必要があるかどうかを簡単に判断できます。

展開に高可用性が必要ないと判断した場合は、冗長性の要件を判別する方法について「冗長性を計画する (Office SharePoint Server)」を参照してください。

いずれかの開始点トポロジの容量を増やし、パフォーマンスを向上させるには、次のどちらかを実行できます。つまり、より多くの容量を備えたサーバー コンピュータを実装してスケール アップするか、トポロジにサーバーを追加してスケール アウトします。ここでは、スケール アウトしたいくつかのトポロジの一般的なパフォーマンス特性について説明します。トポロジの例で、InfoPath Forms Services シナリオのトポロジをスケール アウトする場合の一般的な方法を示します。これには、次のような方法が含まれます。

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

  • さらに大きなデータ負荷に対応するには、データベース サーバー ロールの容量を増やします。これは、単一の (クラスタ化またはミラー化された) サーバーの容量を増やすか、64 ビット サーバーにアップグレードするか、クラスタ化またはミラー化されたサーバーを追加することで行えます。

  • 1 台の (クラスタ化またはミラー化された) データベース サーバー コンピュータにつき 8 台までの Web サーバー コンピュータという比率を維持します。ラボにおけるテストにより、各テスト シナリオにおける Web サーバーとデータベース サーバーの最適な比率が判明しましたが、各自の環境でより堅牢なハードウェアを展開すれば (特にデータベース サーバーのハードウェア)、結果がさらによくなる可能性もあります。

目標スループットの予測

スループットは多くの要素の影響を受けます。ユーザーの数、ユーザー層さの種類、複雑さ、および頻度、操作におけるポストバックの回数、データ接続のパフォーマンスなどです。これらの要素それぞれがファームのスループットに大きな影響を及ぼす可能性があります。展開の計画時には、これらの各要素を慎重に考慮してください。

Office SharePoint Server 2007 は多様な方法で展開および構成できるため、特定の数のサーバーで何人のユーザーをサポートできるのかを簡単に推定することはできません。そのため、運用環境で Office SharePoint Server 2007 を展開する前に、必ず各自の環境でテストを行ってください。

最適化

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

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

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

  • シナリオには、ドキュメント ライブラリへのフォームの保存の代わりに、ライブラリへのフォームの送信を含めることをお勧めします。送信操作では POST 要求かラウンド トリップが 1 回だけトリガされますが、保存操作では POST 要求が 2 回トリガされます。フォームの名前は、ルールまたはフォームのコントロールを使用することで、動的に生成できます。

  • フォームの作成者には、ユーザーの待ち時間を抑えるため、ビューごとのコントロール数を減らすことをお勧めします。先頭ページのビューを最適化するには、リッチ テキスト フィールドなどのリソース コストの高いコントロールは既定のビューではなく次のビューに配置してください。

データベース サーバーの最適化

  • 64 ビット バージョンの SQL Server データベース ソフトウェアを実装することより、データベース サーバーに 64 ビット バージョンの Windows Server 2003 オペレーティング システムを実装することが重要です。これは、64 ビットの Windows Server アーキテクチャの方が優れたアドレス割り当て機能を有し、SQL プロセスでより多くのメモリを使用できるからです。ただし、データベース サーバーの物理メモリがパフォーマンスのボトルネックになっている場合は、64 ビット データベース サーバーの使用も検討してください。SQL Server 2005 については、8 つのプロセッサと、64 ビット バージョンの Windows Server 2003 を使用する 64 ビット コンピュータを組み合わせた構成が推奨されます。

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

パフォーマンス テストにおいて、いくつかの一般的なボトルネックが明らかになりました。ボトルネックとは、ファーム内の特定の構成要素の処理能力が限界に達する状態です。ボトルネックによって、ファームのスループットが停滞または下降します。

次の表に、一般的なボトルネックを示し、原因と解決方法を説明します。

InfoPath Forms Services のボトルネック

ボトルネック 原因 解決方法

データベースの競合 (ロック)

データベースのロックは、複数のユーザーが一連のデータに対して競合する変更を行うことを防ぎます。一連のデータがユーザーまたはプロセスによってロックされると、その他のユーザーまたはプロセスが同一のデータを変更できるのは、最初のユーザーまたはプロセスがデータの変更を終了して、ロックを解放してからです。

データベース ロックの発生を抑えるために次の方法があります。

  • 送信フォームを分散させるドキュメント ライブラリを増やす。

  • データベース サーバーをスケール アップする。

  • データベース サーバーのハード ディスクを読み取り/書き込み用にチューニングする。

SQL Server 2005 には、NOLOCK パラメータなど、データベース ロック システムを回避する方法が存在しますが、データ破損の可能性があるためこの方法はお薦めしません。

データベース サーバーのディスク I/O

ハード ディスクに対する I/O 要求がディスクの I/O 能力を超えると、要求はキューに入れられます。この結果、各要求の実行にかかる時間が長くなります。

データ ファイルを複数の物理ドライブに分散させると並列 I/O が可能になります。ブログ「SharePoint Disk Allocation and Disk I/O (英語)」 (https://go.microsoft.com/fwlink/?linkid=129557&clcid=0x411) には、ディスク I/O の問題を解決するための有益な情報が含まれています。

Web サーバーの CPU 使用率

Web サーバーに対するユーザー要求が過負荷になると、平均 CPU 使用率は 100% に達します。このような場合、Web サーバーは要求にすぐに応答できなくなります。タイムアウトを引き起こし、クライアント コンピュータにはエラー メッセージが表示されることがあります。

この問題は次の 2 つの方法のどちらかを使用して解決できます。つまり、ファームに Web サーバーを追加してユーザー負荷を分散させるか、高速のプロセッサを追加することで Web サーバー (1 台または複数) をスケール アップします。詳細については、「可用性を計画する (Office SharePoint Server)」および「冗長性を計画する (Office SharePoint Server)」を参照してください。

ディスク容量の要件を予測する

以下のセクションでは、このシナリオのディスク容量要件の予測に役立つ表を示します。ハードウェアのディスク容量の要件は、サーバー ロールやシナリオごとに大きく異なります。また、コンテンツ データベースに格納されるデータ、キャッシュの要件、ファームに格納されるフォームとフォーム テンプレートの数とサイズに左右されます。以下の説明では、予測可能なディスク容量の要件に基づき、可能な限り数値が数式に当てはめられています (インストール ファイルのサイズなど)。

まず、サーバー ロールごとのディスク容量要件を予測します。次に、計画中のトポロジに基づき、複数のサーバー ロールが同じ物理サーバー コンピュータを共有する場合について、それらのロールのディスク容量要件を合計します。最後に、使用するハードウェアが、合計したディスク容量要件を満たしていることを確認します。

さらに、SQL Server ストレージのベスト プラクティスをデータベース サーバーに適用します。詳細については、「Physical Database Storage Design (英語)」 (https://go.microsoft.com/fwlink/?linkid=78853&clcid=0x411) を参照してください。複数のデータベース サーバーを実装する場合は、SQL のディスク容量の要素を Web サーバーそれぞれに適用してください。

注意

オペレーティング システムとプログラム ファイルは、データ ファイルとは異なる別のドライブまたは RAID (Redundant Array of Independent Disks) に保存する必要があります。

データベース サーバーのディスク容量要件

次の表を使用して、ファーム内のデータベース サーバーのディスク容量要件を計算します。複数のデータベース サーバーが実装されている場合、各データベース サーバーでこの合計を算出してください。

カテゴリ 説明 値

オペレーティング システム ファイル

Windows Server 2008 のセットアップとシステム ファイルに必要なディスク容量。詳細については、「インストール先パーティションのファイル システムを選択する」(https://go.microsoft.com/fwlink/?linkid=78866&clcid=0x411) を参照してください。

4 GB

ページング ファイル

既定では、ページング ファイルのサイズは物理メモリの容量と同じになります。

SQL Server インストール ファイル

SQL Server のセットアップとプログラム ファイルに必要なディスク容量。詳細については、「SQL Server 2005 Standard Edition システム要件」 (https://go.microsoft.com/fwlink/?linkid=78870&clcid=0x411) を参照してください。

425 MB

データベース ログ ファイル

SharedServices_DB .ldf ファイルは、SharedServices_DB .mdf ファイルと WSS Content_DB を格納するディスク以外のハード ディスクに格納してください。ログ ファイルのサイズは非常に大きくなる場合があるので、管理者はログ ファイル用に専用のディスクを指定することもできます。また、ログ ファイルのサイズが空きディスク容量の 50% 近くに達したらログ ファイルがリサイクルされるように構成してください。

ログ ファイルのディスク容量は、ログ設定およびデータベース数によって異なります。詳細については、「Physical Database Storage Design (英語)」 (https://go.microsoft.com/fwlink/?linkid=78853&clcid=0x411) を参照してください。

構成データベース

通常、構成データベースはこのサイズを超えることはありません。これは推定最大サイズであり、ハード的な制限ではありません。

1.5 GB

コンテンツ データベース

SharedServices_DB.mdf ファイルは、ディスク アレイが最長で容量が最大の仮想ディスクに配置してください。

コンテンツ データベースに保存されるコンテンツの初期ボリュームを予測します。次の点を検討してください。

  • 初期コンテンツのサイズに 1.2 を掛けて、SQL データベース内の保存コンテンツのサイズを算出します。

  • ドキュメントのバージョン管理を使用する場合は、各バージョンのコピーがデータベースで保存されます。

将来的な増加

データ量は初期の展開に含まれる量の 2 倍になると考えておく必要があります。各自の環境に合った数値を入力してください。

空き容量

各ハード ディスクやボリュームに少なくとも 25% の空き容量を残します。

総容量

Web サーバーのディスク容量要件

次の表を使用して、ファームにおける各 Web サーバーのディスク容量要件を計算します。

カテゴリ 説明 値

オペレーティング システム ファイル

Windows Server 2008 のセットアップとシステム ファイルに必要なディスク容量。詳細については、「インストール先パーティションのファイル システムを選択する」(https://go.microsoft.com/fwlink/?linkid=78866&clcid=0x411) を参照してください。

4 GB

ページング ファイル

既定では、ページング ファイルのサイズは物理メモリの容量と同じになります。

Office SharePoint Server 2007 インストール ファイル

1.3 GB

.NET Framework 3.5

60 MB

空き容量

各ハード ディスクやボリュームに少なくとも 25% の空き容量を残します。

総容量

パフォーマンスの監視

システムのスケール アップやスケール アウトを行うべき時期を見極められるように、パフォーマンス カウンタを使用してシステムの正常性を監視してください。次の表の情報を参照して、監視に使用するパフォーマンス カウンタと、その適用対象のプロセスを特定してください。

Web サーバー

次の表に、パフォーマンス カウンタと、ファーム内の Web サーバーにおける監視対象のプロセスを示します。

パフォーマンス カウンタ 適用対象 注

プロセッサ時間

全体

命令を実行するために、このスレッドがプロセッサを使用する時間をパーセントで示します。

メモリ使用率

アプリケーション プール

アプリケーション プールのシステム メモリの平均使用率を表示します。監視対象のアプリケーション プールを特定する必要があります。

基本的に、ある Web アプリケーションのピーク メモリ使用率を識別し、その番号に 10 を足したものを、関連するアプリケーション プールに割り当てます。

データベース サーバー

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

パフォーマンス カウンタ 適用対象 注

ディスク キューの平均の長さ

SharedServices.mdf の含まれるハード ディスク

スピンドルあたりの平均値が 1.5 を上回っている場合は、そのハード ディスクへの書き込みの時間が十分でないことを表します。

プロセッサ時間

SQL Server プロセス

平均値が 80% を上回っている場合は、データベース サーバーのプロセッサの性能が不十分であることを表しています。

プロセッサ時間

全体

命令を実行するために、このスレッドがプロセッサを使用する時間をパーセントで示します。

メモリ使用率

全体

システム メモリの平均使用率を示します。

このドキュメントをダウンロードする

このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なドキュメントに収められています。

入手可能なドキュメントの詳細な一覧については、「Office SharePoint Server 2007 のダウンロード可能なブック」を参照してください。

関連項目

その他のリソース

InfoPath Forms Services 2007 Web Testing Toolkit (英語)