Web コンテンツ管理展開のための SharePoint Server 2010 キャパシティ管理

このドキュメントは現状有姿で提供され、このドキュメント (URL などのインターネット Web サイトにある参照先を含む) に記載されている情報および見解は、将来予告なしに変更することがあります。その使用責任はお客様ご自身にあります。

このドキュメントに記載されている例の一部は、例示のみを目的としており、架空のものです。実在する事物とは一切関係ありません。

このドキュメントは、あらゆるマイクロソフト製品に対する何らかの知的財産権をお客様に付与するものではありません。このドキュメントは、内部的な参照目的にのみコピーおよび使用することができます。

© 2010 Microsoft Corporation. All rights reserved.

Web コンテンツ管理展開のためのSharePoint Server 2010 キャパシティ管理

執筆者 : Joshua Stickler、Tyler Butler テスター : Zhi Liu、Cheuk Dong、Philippe Flamm

Microsoft Corporation2010 年 4 月概要 : このホワイト ペーパーは、SharePoint Server 2010 Web コンテンツ管理 (WCM) ソリューションのキャパシティ管理のガイダンスを提供します。

このホワイト ペーパーでは、次のサイト形式を取り上げます。

インターネット発行サイト イントラネット発行サイト エンタープライズ Wiki

目次前提条件..........................................................................................................................................................6

はじめに..............................................................................................................................................................7

Web コンテンツ管理展開.................................................................................................................................7

最適化に向けた考慮事項...................................................................................................................................8

主要な指標となるスループット..................................................................................................................8

ボトルネックと改善......................................................................................................................................9

フロントエンド Web サーバーの CPU 使用率....................................................................................9

その他のボトルネック............................................................................................................................10

キャッシュの利用効果................................................................................................................................11

テスト結果と推奨事項.....................................................................................................................................11

出力キャッシュを有効にする効果............................................................................................................11

出力キャッシュ ヒット率.......................................................................................................................11

結論と推奨事項........................................................................................................................................13

匿名対認証....................................................................................................................................................13

キャッシュ プロファイル......................................................................................................................14

結論と推奨事項........................................................................................................................................14

読み取り/書き込み操作のスケールアウトの特性...................................................................................15

結論と推奨事項........................................................................................................................................17

出力キャッシュの注意................................................................................................................................18

データ更新................................................................................................................................................18

結論と推奨事項........................................................................................................................................20

CPU と応答時間に対する読み取り量の影響...........................................................................................20

結論と推奨事項........................................................................................................................................20

スループットに対する書き込み操作の影響.............................................................................................20

結論と推奨事項........................................................................................................................................25

コンテンツ展開の影響................................................................................................................................25

フロントエンド Web サーバーの CPU 使用率に対するコンテンツ展開のインポートの影響...27

データベース サーバーの CPU 使用率に対するコンテンツ展開のインポートの影響.................27

結論と推奨事項........................................................................................................................................27

コンテンツ展開のエクスポート中のデータベース スナップショットの影響...................................27

結論と推奨事項........................................................................................................................................28

コンテンツの特性........................................................................................................................................28

ページ数....................................................................................................................................................28

複数値ルックアップ フィールド...........................................................................................................29

利用状況レポートの影響........................................................................................................................30

付録.................................................................................................................................................................... 31

テストの詳細と方法.........................................................................................................................................31

ハードウェア................................................................................................................................................31

フロントエンド サーバーとアプリケーション サーバー.................................................................31

データベース サーバー...........................................................................................................................32

データ セット...............................................................................................................................................32

前提条件このドキュメントを読む前に、Microsoft® SharePoint® Server 2010 のキャパシティ管理の背後にある主要な概念を理解しておく必要があります。次のドキュメントは、推奨されるキャパシティ管理方法の学習に役立つと共に、このドキュメントの情報を効果的に使用する方法を理解するためケース スタディを提供します。

このホワイト ペーパーのデータの背景を理解するために役立つ、パフォーマンスとキャパシティの概念的な情報については、次のドキュメントを参照してください。

SharePoint Server 2010 のキャパシティプランニングとサイズ調整 ( 英語 ) 技術ケース スタディ – エンタープライズ イントラネット発行環境 ( 英語 )

サーバー ファーム

インターネット /

イントラネットの訪問者作成者

はじめに

このホワイト ペーパーでは、次のシナリオを取り上げます。

インターネット発行サイトo 例 : 会社案内サイト

イントラネット発行サイトo 例 : 社内ニュース サイト

エンタープライズ Wikio 例 : ナレッジ リポジトリ

このドキュメントを読むことで、次の概念を理解できます。

大量の読み取り操作をサポートするために最大化する必要がある主要な指標としてのスループット

Web コンテンツ管理の SharePoint Server 2010 展開に関連する潜在的な各種ボトルネック

スループットの最大化における出力キャッシュの重要性

エンド ユーザーの読み取りエクスペリエンスに対する書き込み操作の影響

Web コンテンツ管理展開このホワイト ペーパーは、発行インフラストラクチャが有効にされた SharePoint サイトに関連するキャパシティ管理のガイダンスを提供します。SharePoint 発行サイトでコンテンツを作成するためのモデルは 2 つあり、それぞれがサーバー ファームのトポロジの選択に影響を及ぼします。

作成者インプレース モデルでは、1 つのサイト コレクションが作成者と訪問者に共有されます。作成者はいつでもコンテンツを作成および更新でき、1 日中読み書き操作を自由に配信できます。通常、このサーバー ファームには、多数の読み取りと中程度の書き込みの負荷がかかります。

作成環境 発行環境

インターネット /

イントラネットの訪問作成者

コンテンツ展開

コンテンツ展開モデルでは、複数のサイト コレクションが独立して排他的にコンテンツの作成と発行をサポートします。コンテンツは、作成環境で作成および更新され、次に訪問者が読むためにスケジュールベースで発行環境に展開されます。発行環境は、コンテンツが作成環境から展開されている場合を除き、主に読み取り要求を処理します。作成者インプレース モデルとは異なり、コンテンツ展開によって発生するサーバー負荷を調整して、その間隔をスケジュールできます。

これらのコンテンツ作成モデルは、相互に排他的です。インターネット発行サイトとイントラネット発行サイトは、作成者インプレースまたはコンテンツ展開のいずれかを使用できますが、エンタープライズ Wiki は、作成者インプレース モデルで最適に機能します。

エンタープライズ Wiki は、投稿者が新しいページを作成し、既に存在するまたは存在しない別のページへのリンクを張ることで有機的に成長する単一ファーム サイトです。このサイトを使用すると、会社または組織全体の人々が SharePoint 環境として統合および拡張される 1 つのソリューションを使用して、知識を得たり共有することができます。一般にエンタープライズ Wiki では、ページを編集するユーザーの割合が高いため、読み取り操作に比べて比較的大量の書き込み操作が行われます。エンタープライズ Wiki ページは、発行される記事ページとは異なるパフォーマンス特性を示します。

最適化に向けた考慮事項

主要な指標となるスループットSharePoint Server 2010 WCM 展開のキャパシティプランニングをする場合、スループットと応答時間は、最適化の対象になる最も重要な指標です。スループットは、サーバー ファームが 1 秒間に実行できる操作の数で、RPS (Requests per Second :1 秒あたりの要求数) で測定されます。

ボトルネックと改善

ボトルネックは、システムリソースが完全に利用されるとサーバー ファームがそれ以上要求を処理できなくなることを意味します。

フロントエンド Web サーバーの CPU 使用率フロントエンド Web サーバーの CPU は最もスケーラブルなコンポーネントであり、適切に調整されたトポロジでは、ここがボトルネックになっているはずです。ロード バランサーは、要求をフロントエンド Web サーバー間でルーティングして、1 台のサーバーが他のサーバーと比較して大幅に使用されることがないようにします。

フロントエンド Web サーバーの CPU 使用率が上限に達した後もさらにユーザーがサイトを訪問することはできますが、このようなユーザーに対するサーバーの応答時間は増します。この動作は、要求量の一時的な増大を管理するために便利です。ただし、サーバー ファームのキャパシティを超えた負荷が継続すると、最終的には要求のバックログが増え、待機中の要求のしきい値を超えます。この時点で、フロントエンド Web サーバーは要求を制限し、HTTP エラー 503 で応答します。 図2 では、待機中の要求のしきい値を超えた後は HTTP エラーのみが処理されるため、サーバーの応答時間は減少しています。

図 1

1. フロントエンド Web サーバーの CPU 使用率が 100% に近づく2. 待機中の要求のしきい値を超過した後の要求はエラーとして処理される

その他のボトルネックフロントエンド Web サーバーの CPU がボトルネックでない場合は、ファーム トポロジ、ファーム構成、または処理されるページのコンテンツを調査する必要があります。潜在的なボトルネックには、次のものがあります。

1. ネットワーク : スループットが高い場合は、ネットワークがフロントエンド Web サーバーとデータベース サーバーの間またはフロントエンド Web サーバーとエンド ユーザーの間で飽和状態になる可能性があります。この状態を避けるには、フロントエンド Web サーバーでデュアル ギガビットの NIC を使用することをお勧めします。

2. データベース サーバーの CPU : データベース サーバーの CPU がボトルネックになった場合は、サーバー ファームにフロントエンド Web サーバーを追加してもファームがサポートできる最大スループットは増えません。これは、次の 2 つの状況を反映している可能性があります。

a. キャッシュの設定が適切でない、またはページが非常に遅い (特に出力キャッシュが構成されていない場合)。これは、データベース サーバーの CPU 使用率は高いが、スループットが小さいか中程度で、フロントエンド Web サーバーの使用率が低いか中程度であることが特徴です。

b. データベース サーバーがファームに必要なスループットの最大キャパシティに達した可能性がある。これは、スループットが高く、フロントエンド Web サーバーとデータベース サーバーの CPU 使用率が高いことが特徴です。

キャッシュの利用効果SharePoint Server 2010 は 3 種類のキャッシュを使用します。これらのキャッシュに共通する目的は、頻繁に要求されるデータに対するデータベースへの呼び出し回数を減らして、効率を向上させることです。あるページに対する 2 回目以降の要求は、フロントエンド Web サーバーのキャッ

Response Time vs. Resource Utilization

Active Users

Resp

onse

Tim

e

12

図 2

シュによって処理され、結果的にフロントエンド Web サーバーとデータベースのリソースの使用率が大幅に減ります。

出力キャッシュo 要求されたページ コンテンツをフロントエンド Web サーバーのメモリに保存するo 「出力キャッシュとキャッシュ プロファイル 」を参照

オブジェクト キャッシュo Web やリスト項目のメタデータなどの SharePoint オブジェクトをフロントエン

ド Web サーバーのメモリに保存する o 「オブジェクト キャッシュ 」を参照

BLOB (Binary Large Object) のディスク ベースのキャッシュo イメージ、サウンド、ビデオ ファイルをディスクに保存するo 「BLOB のディスク ベースのキャッシュ 」を参照

高いスループットを維持するには、どのキャッシュも重要です。ただし、出力キャッシュの効果が最も高く、このホワイト ペーパーでは出力キャッシュについて詳細に説明します。

テスト結果と推奨事項

出力キャッシュを有効にする効果出力キャッシュは、大量の読み取り操作がある SharePoint Server 2010 ソリューションを最適化するための重要な機能です。

最大 RPS を判断するために、データベース サーバーまたはフロントエンド サーバーのいずれかの CPU 使用率が 100% に達してボトルネックになるまで、ファーム内で要求を行うアクティブ ユーザーの数を増やしました。1x1、2x1、4x1、8x1 の各ファーム トポロジで、さまざまな出力キャッシュ ヒット率のフロントエンド Web サーバーをスケールアウトすることの効果を例証するためのテストを行いました。

出力キャッシュ ヒット率出力キャッシュ ヒット率は、出力キャッシュのヒットとミスの割合を示す測定基準です。

キャッシュ ヒットとは、既にキャッシュに保存されているオブジェクト データに対する要求をキャッシュが受け取ることです。

キャッシュ ミスは、キャッシュに保存されていないオブジェクト データが要求されることです。キャッシュ ミスが発生した場合、キャッシュは、要求されたオブジェクト データの保存を試みます。そのデータに対する後続の要求をキャッシュによって処理できれば、それらの要求はキャッシュ ヒットになります。

ページ要求がキャッシュ ミスになる理由はいくつかあります。

ページが出力キャッシュを使用するように構成されていない ページがパーソナライズされている。たとえば、現在のユーザーに固有のデータがページ

に含まれる 異なる出力キャッシュ キーに対して初めて参照された キャッシュされたコンテンツが期限切れになった後に初めて参照された

1x1 2x1 4x10

2000

4000

6000

8000

10000

12000

Effect of Output Caching on Peak Throughput

100%95%90%50%0%

Farm Topology

Peak

Thr

ough

put (

RPS)

Output Cache Hit Ratio:

図 3

出力キャッシュ ヒット率が 100% の 4X1 サーバー ファームでの最大 RPS データの値は推測値であり、測定値ではありません。これは、サーバー ファームの要求量がネットワーク帯域幅の限界 (データ転送率が 1 秒あたり 1 ギガビット) に達したためです。どの場合も、フロントエンド Web サーバーの CPU 使用率は 100% です。

表１

出力キャッシュ ヒット

率測定基準 1x1 2x1 4x1

100% 最大 RPS 3,463 7,331 11,032SQL Server CPU 使用率 0% 0% 0%

95% 最大 RPS 2,137 3,945 5,937SQL Server CPU 使用率 5.93% 12.00% 21.80%

90% 最大 RPS 1,518 2,864 4,518SQL Server CPU 使用率 7.12% 14.40% 28.00%

50% 最大 RPS 459 913 1,596SQL Server CPU 使用率 9.86% 19.50% 42.00%

0% 最大 RPS 172 339 638SQL Server CPU 使用率 9.53% 19.00% 36.30%

結論と推奨事項出力キャッシュ率が高くなると、最大 RPS が大幅に増加します。そのため、出力キャッシュを有効にして SharePoint Server 2010 発行ソリューションを最適化することをお勧めします。出力キャッシュは、[サイト コレクションの管理] -> [出力キャッシュの設定] で構成できます。

出力キャッシュを有効にしたテストでは、ページのキャッシュが行われる最初の要求は除外しました。つまり、一定割合のページが既にキャッシュに保存されているということです。ユーザーがキャッシュされていないページを最初に要求したときに、そのページがキャッシュに追加されます。キャッシュは、容量の限界に達するか、近づくと、最初に要求されたデータを削除します。

キャッシュ ヒット率 0% は、出力キャッシュが有効でない環境と、キャッシュは有効だが、フラッシュされたキャッシュが満たされるまでの短時間に見られる環境をシミュレートしています。たとえば、実際の環境では、アプリケーション プールがリサイクルするときに毎日この状態が観察されます。そのため、ハードウェアを適切にスケーリングして、アプリケーション プールがリサイクルしてから次にページの要求とキャッシュが行われるまでの短い期間キャッシュ ヒット率が 0% になる状況に対応する必要があります。

匿名対認証前のテストは、サイトへのすべての要求が匿名の読者によって行われると仮定しています。ただし、実際のサイトでは、一部のユーザーまたはすべてのユーザーが認証される場合があります。認証付きの読み取りが行われる例には、企業イントラネット発行サイトやインターネットのメンバー専用コンテンツがあります。

出力キャッシュ プロファイルを使用すると、認証されたユーザーと匿名ユーザーにそれぞれ異なる出力キャッシュ動作を指定できます。

キャッシュ プロファイルキャッシュ プロファイルは、サイト展開に含まれるページ、ページ項目、コンテンツ タイプ、およびスケールのレベルに適用できる設定をまとめたものです。キャッシュ プロファイルでは、次のキャッシュの動作を定義します。

項目をキャッシュ内に維持する期間 セキュリティによるトリミングのポリシー 継続時間、変更などの設定の有効期限 ユーザー アクセス許可、ユーザー権利などのカスタムな可変要素に基づくキャッシュされ

るコンテンツの変更

キャッシュ プロファイルを変更すると、即座にサイト内のすべての該当するコンテンツに反映されます。匿名ユーザーと認証されたユーザーに異なるキャッシュ プロファイルを設定できます。

匿名ユーザーには [パブリック インターネット (匿名専用)] 出力キャッシュ プロファイルを、認証されたユーザーには [エクストラネット (発行済みサイト)] 出力キャッシュ プロファイルを使用しました。

1x1 2x1 4x10

500

1000

1500

2000

2500

3000

3500

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Effect of Authenticated Throughput on Database Server CPU Uti-lization

Authenticated Read RPS Database server CPU utilization

認証モデルは Windows 基本認証を使用しました。Windows 基本認証をインターネット サイトで使用することは推奨されませんが、認証による最小限のオーバーヘッドを実証するために、この認証方法を選択しています。このオーバーヘッドのサイズは、使用する認証メカニズムによって変化します。したがって、展開をテストする場合は、認証メカニズムの影響を考慮する必要があります。SharePoint Server 2010 がサポートする認証メカニズムの詳細については、「認証方法の計画 (SharePoint Server 2010) 」を参照してください。

結論と推奨事項資格情報の検証作業はデータベース サーバーに負荷を加えるので、認証されたユーザーは、RPS が低くなり、スケールアウトの効果も小さくなります。テスト結果から明らかなように、ユーザーを認証する場合の最大 RPS は、匿名アクセスのファームより大幅に低下します。

読み取り/書き込み操作のスケールアウトの特性WPH (1 時間あたりの書き込み数) を記録するためのテストを行いました。このホワイト ペーパーでは、1 回の書き込みを、1 つの新しい発行ページの作成およびチェックインまたは 1 つの既存の発行ページの編集およびチェックインと定義しています。

以下のテストでは、フロントエンド Web サーバーの CPU 使用率が約 80 ～ 90% に達するまでシステムに読者を追加し、人為的な遅延を使用した環境で書き込み操作を行いました。テストの全体 WPH は約 500 でした。すべてのテストで 90% の出力キャッシュ ヒット率を使用しました。1x1、2x1、4x1 の各ファームで同じテストを行い、各構成のフロントエンド Web サーバーと Microsoft SQL Server® の CPU 使用率に加えて、全体的な読み取りスループットを観察しました。さらに、ベースラインとして匿名の読み取り専用の構成をテストし、Windows 基本認証を使用して認証される読者の構成もテストしました。

読み取り専用のスケールアウト テストでは、フロントエンド Web サーバーの CPU を使用率 100% の上限まで使用し、一方、書き込みのスケールアウト テストでは、フロントエンド Web サーバーの CPU 使用率を 80 ～ 90% に維持しました。これは、書き込みアクティビティを実行する際に CPU 使用率に余裕を残すためです。

図 4 は、各テスト中の全体的な読み取り RPS を示しています。読み取り RPS は、書き込みアクティビティがある場合でも、WFE が追加されると線形でスケーリングします。ただし、書き込みが組み合わさると RPS は損なわれます。

1x1 2x1 4x10

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

Scale-out Characteristics of Read/Write Op-erations

RPS - Anonymous Read; No Writes RPS - Anonymous Reads; Authenticated WritesAuthenticated Reads; No Writes Authenticated Reads; Authenticated Writes

Server Farm Topology

Thro

ughp

ut (R

PS)

図 4

データベース サーバーの CPU 使用率は、フロントエンド Web サーバーの数が増えると増加しました。 図 5５ は、さまざまな構成における SQL Server の CPU 使用率の増加パターンを示しています。上の匿名対認証のテスト結果からわかるように、認証はデータベース サーバーの CPU 使用率に影響を及ぼし、書き込みアクティビティ (同様にデータベース サーバーの CPU 使用率に影響を及ぼす) が加わると、それがさらに顕著になります。

SQL Server の使用率の変化を予測すると、認証付きの読み取り要求がある 6 台のフロントエンド Web サーバーでは、SQL Server がボトルネックになることが示されます。ただし、匿名読み取りのケースでは、フロントエンド Web サーバーの数を増やしてスケールアウトする方が有効です。

標準的な展開には、データベース サーバーの負荷に影響を及ぼすため、キャパシティプランニングの際に考慮する必要がある要素がほかにもいくつかあります。標準的なデータベース サーバーの CPU 使用率にグリーン ゾーンを設定する方法については、「Capacity Management Overview ( キャパシティ管理の概要 ) 」を参照してください。

1x1 2x1 4x1 8x1 9x110x1

11x112x1

0

10

20

30

40

50

60

70

80

90

100

Effect of Read/Write Load on Database Server CPU Uti-lization

Anonymous Read; No WritesLinear (Anonymous Read; No Writes)Anonymous Reads; Authenticated WritesLinear (Anonymous Reads; Au-thenticated Writes)Authenticated Reads; Authen-ticated WritesLinear (Authenticated Reads; Au-thenticated Writes)

Server Farm Topology

% C

PU U

tiliza

tion

図 5

結論と推奨事項このデータは、データベース サーバーがボトルネックにならない限りは、フロントエンド Web サーバーの数をスケールアウトすることがスループットを向上させるための効果的な戦略であることを示しています。平均的には、匿名の読み取り/認証付き書き込みのテスト ミックスは、匿名の読み取り/書き込みなしのテスト ミックスと比較して、フロントエンド Web サーバーの CPU 使用率が 52% 増加しました。さらに、認証付きの読み取りでは、各要求で追加的な認証チェックが発

生し、SQL Server へのラウンドトリップが必要になるため、SQL Server の負荷が大きくなります。

1x1 2x1 4x10

1000

2000

3000

4000

5000

6000

0

10

20

30

40

50

60

70

80

90

100

Effect of Throughput on Database Server CPU Utilization

SQL CPU - Anonymous Read Only SQL CPU - Anonymous Read/WriteRPS - Anonymous Read; No Writes RPS - Anonymous Reads; Authenticated Writes

Thro

ughp

ut (R

PS)

SQL C

PU %

図 6

出力キャッシュの注意キャパシティプランニングにおける関心事が RPS を最大化することだけであれば、以上のテストから、最適なキャッシュ ヒット率は 100% であることが示唆されます。ただし、データ更新の要件やメモリの制約により、一部または全部のページの出力キャッシュを有効にすることが実現不可能であるか、好ましくない場合があります。

データ更新出力キャッシュから提供されるデータには、元のコンテンツに行われた最新の更新内容が含まれていない可能性があります。コンテンツ展開シナリオまたは作成者インプロダクション シナリオ (認証された作成者の場合) のソースでは、作成者が既存のコンテンツの更新後即座に最新の変更内容を表示できると便利です。

この時間差を減らすには、通常、キャッシュ プロファイルの [期間] プロパティを設定します。このプロパティは、出力キャッシュに置かれたキャッシュ ページが期限切れになるまでの時間を指定します。期限切れになったページはキャッシュから削除され、次の要求はキャッシュ ミスになり、そこでページ コンテンツが更新されます。

[変更を確認する] キャッシュ プロファイル プロパティを設定して、ページがキャッシュされた時刻とサイト コレクション内のコンテンツが最後に変更された時刻をサーバーで比較することもできます。タイムスタンプが一致しないページに対する要求があった場合は、サイト コレクション内のすべてのページのキャッシュが無効化されます。[変更を確認する] は、サイト コレクション内のすべてのページに影響を及ぼします。したがって、頻繁に更新されないために実質的に静的な認証付き作成者インプレース ソリューションでのみ、この設定を有効にすることをお勧めします。このオプションと長い [期間] オプションを組み合わせると、サイトに更新が行われるまでは、すべてのページをキャッシュから提供できます。

既定では、[変更を確認する] は有効になっていません。つまり、フロントエンド Web サーバーは、基になるオリジナル ASPX ページが変更されているかどうかに関係なく、期限切れになっていないページに対する要求は、出力キャッシュのデータを使用して処理します。

このテストは、1x1 のサーバー ファームで行いました。[変更を確認する] を有効にしたこと以外はすべて「読み取り/書き込み操作のスケールアウトの特性」と同じです。[変更を確認する] がオンの場合、キャッシュは頻繁にフラッシュされるため、出力キャッシュ ヒット率が低くなります。

Off On0

100

200

300

400

500

600

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Effect of Check for Changes on Throughput

Read RPS Output Cache Hit Ratio

Check for Changes Setting

Thro

ughp

ut (R

PS)

Out

put C

ache

Hit

Ratio

[変更を確認する] 出力キャッシュ プロファイル設定は、特殊な場合を除き、使用しないことをお勧めします。作成者インプレース モデルを使用し、コンテンツがあまり頻繁に変更されないサイトでは、この設定を長いキャッシュ時間と組み合わせた場合に、認証されたユーザーにとってメリットがあることもあります。ただし、その他のサイトでは、多くの場合に RPS が低下します。

要件によっては、時間での対応が重要であるコンテンツを即座に、または既定の設定より素早くに有効にする必要がある場合があります。その場合は、[期間] 設定を小さくするか、出力キャッシュを無効にします。

結論と推奨事項出力キャッシュは、キャパシティ管理に関連するすべての問題を解決できるわけではありません。出力キャッシュが適切でない状況もあるため、出力キャッシュを有効にしたり、出力キャッシュ プロファイルを構成する際は、そのような状況を考慮する必要があります。

CPU と応答時間に対する読み取り量の影響このテストは、匿名アクセスと出力キャッシュが有効な 1x1 ファームで行いました。

結論と推奨事項「ボトルネックと改善」で説明したように、フロントエンド Web サーバーが十分な量の要求を受け取り、CPU を完全に使用するまでは、通常、サーバーの応答時間は一定のままです。フロントエンド Web サーバーの CPU 使用率が上限に達すると、応答時間は大幅に増加しますが、サーバー ファームはまだいくらかの要求量を処理できます。

スループットに対する書き込み操作の影響作成操作と編集操作をテスト全体で均等な割合になるように分散させました。WPH(Write per Hour) 値を最大約 500 までテストしました。1 時間に 500 ページ以上の作成/編集は、大部分の SharePoint 展開が運用される範囲を超えているためです (「コンテンツ展開の影響」で説明されているコンテンツ展開などの自動プロセスを除く)。この作成/編集操作では、複数の SQL Server 操作が発生する場合があるため、これらのテストで測定される書き込み数は、SQL Server レベルではなく、ユーザーが行う書き込み操作であることに注意してください。すべての RPS 対 WPH テストは、1x1 ファームで行いました。

0

500

1000

1500

2000

2500

3000

3500

4000

0

0.002

0.004

0.006

0.008

0.01

0.012

Effect of Read Volume on CPU, Response Time100% Output Cache Hit Ratio

Latency RPS

Front-end Web server CPU Utilization

Thro

ughp

ut (R

PS)

Late

ncy

(s)

最初に、トラフィックの一時的な増大に備えた余裕を残して、フロントエンド Web サーバーの CPU が 60 ～ 80% になるまでテストに読み取り操作を追加し、テスト全体でこの平均の使用レベルを維持しました。次に、人為的な遅延を使用して書き込み操作の数を制御しながら、書き込みを導入しました。ただし、書き込みが発生している間は、フロントエンド Web サーバーと SQL Server の CPU 使用率の上昇と共に一時的な増大がありました。キャッシュ ヒット率によっては、平均はグリーン ゾーンに収まっていても、一時的な増大のいくつかがグリーン ゾーンのしきい値を超えることがありました (例は 図 11 を参照)。

0 100 200 300 400 500 6000

500

1000

1500

2000

2500

Effect of Write Operations on Throughput

100% Cache Hit99% Cache Hit98% Cache Hit95% Cache Hit90% Cache Hit50% Cache Hit0% Cache Hit

Writes/Hour (WPH)

Thro

ughp

ut (R

PS)

図 7

図 7 からわかるように、環境に書き込みを追加すると、スループットがわずかに減少します。このグラフは、読み取り専用のシナリオと約 500 WPH までの読み取り操作の間のスループットの差を示しています。出力キャッシュ ヒット率ごとに 2 つのデータ ポイントが記録されています。そのため、データ ポイント間の関係は必ずしも比例になっていません。

図 8 に示されているように、キャッシュ ヒット率が低いほど減少割合は大きくなっています。全体的な読み取り RPS は、書き込みに関係なくキャッシュ ヒット率の大きな影響を受けます。

100% Cache Hit

99% Cache Hit

98% Cache Hit

95% Cache Hit

90% Cache Hit

50% Cache Hit

0% Cache Hit0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Throughput Reduction due to Write Volume~500 WPH vs. 0 WPH

% R

edut

cion

in R

PS

図 8

図 9 は、システムに書き込みを追加した場合に、データベース サーバーの CPU 使用率が目に見えては増加しなかったことを示しています。縦軸は、CPU キャパシティの 0 ～ 10% です。

0 100 200 300 400 500 6000

1

2

3

4

5

6

7

8

9

10

Average Database Server CPU Utilization vs. WPH

100% Cache Hit99% Cache Hit98% Cache Hit95% Cache Hit90% Cache Hit50% Cache Hit0% Cache Hit

Writes/Hour

Aver

age

Data

base

Ser

ver C

PU U

tiliza

tion

%

図 9

書き込み操作中に別の SQL Server の負荷が確認されました。これは予想されることですが、最大でも増加は 2.06% だけなので、これは無視できます。すべてのテストでデータベース サーバーの平均 CPU 使用率は 10% 未満にとどまりました。このテストは 1x1 のファームで行われたことに留意してください。フロントエンド Web サーバーの数がスケールアウトすると、データベース サーバーの CPU 使用率は増加します。これについては、後ほど「読み取り/書き込み操作のスケールアウトの特性」で説明します。

テスト中にフロントエンド Web サーバーの CPU 使用率も測定しました。 図 10 は、WPH が 500 に近づいたときでも、テスト全体でフロントエンド Web サーバーの平均 CPU 使用率が 60 ～ 80% に留まったことを示しています。

50

55

60

65

70

75

80

85

90

Front-end Web Server CPU Utilization vs. WPH

OvertaxedNormal Operation100% Cache Hit99% Cache Hit98% Cache Hit95% Cache Hit90% Cache Hit50% Cache Hit0% Cache Hit

Writes/Hour

% F

ront

-end

Web

Ser

ver C

PU U

tiliza

tion

図 10

ただし、実際に測定された CPU 使用率は、書き込みが発生すると一時的に増大しました ( 図 11)。一般に、このような CPU の一時的な増大は問題になりません。グリーン ゾーンの目的は、CPU の負荷の一時的な増大を吸収するための “余裕” を CPU に持たせることです。また、フロントエンド Web サーバーを追加すると、一時的な増大の影響はサーバー間に分散するため、1 台のフロントエンド Web サーバーの CPU への影響は軽減されます。ただし、実際の展開では、このような一時的な増大が予想されることに注意してください。書き込みアクティビティは均一に分散せずに、むしろ一気に発生しがちです。

00:00.0

01:00.0

02:00.0

03:00.0

04:00.0

05:00.0

06:00.0

07:00.0

08:00.0

09:00.0

10:00.0

11:00.0

12:00.0

13:00.0

14:00.0

15:00.0

16:00.0

17:00.0

18:00.0

19:00.0

20:00.055

60

65

70

75

80

85

90

Front-end Web Server CPU Utilization with Writes

90% Cache Hit Ratio, 1x1 Farm

OvertaxedGreen ZoneCPU %

Time

% F

ront

-end

Web

Ser

ver C

PU U

tiliza

tion

図 11

標準的な展開としては、90% のキャッシュ ヒット率は実際には非常に低いことに注意してください。大量の読み取り操作を伴う大部分の SharePoint 展開では、出力キャッシュ ヒット率が 95% 以上になります。

結論と推奨事項提示されたデータは、書き込み操作が読者にとってシステムの全体的なスループットに大きな悪影響を及ぼさないことを示しています。書き込みアクティビティは、CPU 使用率を一時的に増大させる可能性があることを認識し、このような一時的な増大を予測して標準的な構成を計画することが重要です。このような一時的な増大を平均化するための戦略として、複数の WFE へのスケールアウトがあります。これには、書き込みの負荷を複数の WFE に分散させて一時的な増大を全体的に滑らかにすることと、特に高い出力キャッシュ ヒット率で高い読み取り RPS を提供することの両方のメリットがあります。

コンテンツ展開の影響作成者インプレース モデルでは、1 つの環境を編集と読み取りに使用しますが、これに変わる選択肢として、作成環境と運用環境の 2 つの独立した環境に分割し、コンテンツ展開を使用してコンテンツを作成環境から運用環境にコピーする方法があります。

この構成の場合は、コンテンツ展開がコンテンツをインポートしている間を除くと、運用環境にほとんど書き込みアクティビティがありません。以下のテストでは、フロントエンド Web サーバーの CPU 使用率が 70 ～ 80% になるまで読み取りを追加しました。次に、コンテンツ展開ジョブで、それぞれ 500 ページから成る 10 個のサイトを 1 つのパッケージとして作成サイト コレクション

からエクスポートし、そのパッケージを発行サイト コレクションにインポートしました。コンテンツ展開ジョブの期間を十分に延ばしてテスト結果を観察できるように、展開されるパッケージのサイズは、実際の環境で一般に見られるサイズより大きくしています。展開されたコンテンツの特性については、「 データ セット」のセクションを参照してください。

エクスポートが完了したら、コンテンツを別のサイト コレクションにインポートして、インポート進行中のアプリケーション サーバーと SQL Server の負荷とスループットを測定しました。インポート テストは、さまざまな出力キャッシュ ヒット率で行いました。

主な所見は、インポートは全体的な読み取り RPS にわずかな影響しかないということです ( 図 12)。また、インポートはキャッシュ ヒット率に関係なく、フロントエンド Web サーバーの CPU 使用率にも目に見える影響はありませんでした ( 表 1)。ただし、SQL Server の CPU にははっきりした影響がありました (Error: Reference source not found)。コンテンツのインポートではデータベース サーバーに余分な負荷がかかるため、このことは予想されます。ただし、SQL Server の CPU 使用率は、インポート中でもすべてのキャッシュ ヒット率のテストで 12% 未満に留まりました。

100% 99% 98% 95% 90% 50% 0%0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Effect of Content Deployment Import on Throughput

Import

Output Cache Hit Ratio

Read

uctio

n in

Thr

ough

put (

RPS)

図 12

フロントエンド Web サーバーの CPU 使用率に対するコンテンツ展開のインポートの影響

表 1

キャッシュヒット

100% 99 98 95 90 50 0

ベースライン 72.32% 73.26% 71.28% 73.53% 71.79% 68.05% 63.97%インポートあり

70.93% 74.45% 69.56% 74.12% 70.95% 67.93% 63.94%

データベース サーバーの CPU 使用率に対するコンテンツ展開のインポートの影響表 2

キャッシュヒット

100% 99% 98% 95% 90% 50% 0%

ベースライン 1.19% 1.64% 2.01% 3.00% 3.73% 5.40% 6.82%インポートあり

6.03% 6.82% 6.97% 7.96% 8.52% 10.29% 10.56%

結論と推奨事項テストの結果は、通常のサイト操作中にコンテンツ展開操作を行ってもパフォーマンスの点では大きな問題が発生しないことを示しています。この結果は、全体的なパフォーマンスに対する操作の影響を最小限に抑えるためにトラフィックの少ない期間にコンテンツを展開する必要は必ずしもなく、展開時期は、パフォーマンス要件ではなく主にビジネス ニーズによって決定してもよいことを示しています。

コンテンツ展開のエクスポート中のデータベース スナップショットの影響SharePoint Server 2010 では、コンテンツをエクスポートする前にソース コンテンツ データベースのスナップショットを作成するようにコンテンツ展開を構成できます。これにより、エクスポートの実行中に発生する可能性がある作成アクティビティから効果的にエクスポート プロセスを保護できます。ただし、スナップショットは、書き込みを倍増させるため、データベース サーバーの書き込みパフォーマンスに影響を及ぼす場合があります。たとえば、ソース データベースのスナップショットが 2 つあり、そのソース データベースに書き込みを行う場合、データベース サーバーは、既存のデータをそれぞれのスナップショットにコピーしてから、新しいデータをソース データベースに書き込みます。つまり、ソース データベースへの 1 回の書き込みで、実際にはソース データベースへの書き込みと各データベース スナップショットへの書き込みの 3 回の書き込みが発生します。

作成環境でのスナップショットの影響を判断するために、書き込みアクティビティも発生させながら、エクスポート操作中の書き込み RPS、応答時間、およびフロントエンド Web サーバー、データベース サーバー、アプリケーション サーバーの CPU 使用率を測定しました。その結果を 表 3 に示します。

表 3

4 WPHスナップショット

なし

4 WPHスナップショッ

トあり 書き込み RPS 0.2 0.16

応答時間 0.13 0.15フロントエンド Web サーバー CPU % 0.42 0.27アプリケーション サーバー CPU% 8.67 8.98データベース サーバー CPU% 3.34 2.41

8 WPHスナップショット

なし

8 WPHスナップショッ

トあり 書き込み RPS 0.44 0.44

応答時間 0.13 0.13フロントエンド Web サーバー CPU % 0.61 0.73アプリケーション サーバー CPU% 14.6 12データベース サーバー CPU% 7.04 7.86

結論と推奨事項このテストの結果は、データベース スナップショット付きで測定されたデータ ポイントに大きな影響がないことを示しています。記録された変位はいずれも許容範囲内です。これにより、大きなパフォーマンスの制限はなく、データベース スナップショットを使用できることが確認されました。

コンテンツの特性1 組の質問に回答するように設計された 1 つのデータ セットでテストを行いました。実際のデータ セットはさまざまで、時間の経過と共に変化します。このセクションでは、ページ ライブラリ内のページ数やページに含まれる機能などのコンテンツの特性がキャパシティ管理の決定に影響する方法を調査します。

ページ数さまざまなサイズのページ ライブラリで最大 RPS をテストしました。このテストは、出力キャッシュを無効にした匿名アクセスの 4x1 トポロジで行いました。どのページも、未圧縮状態で 42 KB、圧縮状態で 12 KB でした。

ページ数 3 1,00 20,0

0 00最大 RPS 860 801 790

ページ数を 20,000 に増やしても、最大 RPS に大きな影響はありませんでした。

複数値ルックアップ フィールド複数値ルックアップ フィールドは、別のリスト内の 1 つ以上の項目 (管理されたメタデータを使用する列など) を参照する、リスト内の列です。通常、これらのフィールドはページの検索キーワードとして使用され、必ずしも表示はされません。エンタープライズ Wiki などでは、これらのフィールド値をページのコンテンツに出力すると有効な場合もあります。たとえば、ページの作成時にページをいくつかのカテゴリ (ニュース サイトの場合は、「海外」、「社会」、「スポーツ」など) にまとめ、そのページにどのカテゴリのタグが付いているかをエンド ユーザーに示すためのプレースホルダーをマスター ページに入れることができます。

実際には、ページが要求されるたびに複数値ルックアップ フィールドによって多くのデータが取得されるため、ページに多数の複数値ルックアップ フィールドがあると、パフォーマンスに影響を及ぼす場合があります。このシナリオを次のように詳細にテストしています。

0 2 4 6 8 10 12 14 16 18 200

50

100

150

200

250

300

350

Effect of Multivalued Lookup Fields on Throughput

Maximum RPS

Multivalued Lookup Fields Requested

Max

imum

Thr

ough

put (

RPS)

0 5 10 15 200%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Effect of Multivalued Lookup Fields onFarm Resource Utilization

Front-end Web server CPU SQL Server CPU SQL Server Network

Multivalued Lookup Fields Requested

Reso

urce

Util

izatio

n

複数値ルックアップ フィールドの数が増えると、フロントエンド Web サーバーとデータベース サーバーの間のネットワークに影響があるため、最大 RPS の低下が発生します。

利用状況レポートの影響利用状況レポートは、管理者がサイトの使用に関する統計情報を監視するためのサービスです。SharePoint Server の利用状況レポートの詳細については、「利用状況レポートを構成 する 」を参照してください。

利用状況レポートのタイマー ジョブが 1x1 ファームの最大 RPS に及ぼす影響をテストしました。

利用状況データ収集DBオン

利用状況データ収集DB オフ

差

出力キャッシュ オン

3459 RPS 3463 RPS 4 RPS

出力キャッシュ オフ

629 RPS 638 RPS 9 RPS

この結果は、利用状況のログを有効にしても、読み取り専用のシナリオでは RPS に大きな影響はないことを示しています。

付録

テストの詳細と方法o サイト コレクション機能

o SharePoint Server 発行インフラストラクチャ出力キャッシュは、SharePoint Server 発行インフラストラクチャが有効にされている場合に限り使用できます。発行ポータルは、この機能が既定で有効になっています。

各テストでは、実際に見られる可変要素のいくつかを抜き出して、具体的な推奨事項を示しました。そのため、現実の環境では、正しいスケーリングによって必要な要求量が満たされていることを確認するためのテストと監視が重要です。キャパシティ管理の概念について詳細に学習するには、「Capacity Management Overview (キャパシティ管理の概要)」を参照してください。

ハードウェアフロントエンド サーバーとアプリケーション サーバー

ファーム内の Web サーバーの数はテストごとに異なりますが、それぞれのハードウェアは同じです。

Web サーバー WFE

プロセッサ 2 クアッドコア 2.33 GHzRAM 8 GBオペレーティング システム

Windows Server® 2008、64 ビット

SharePoint ドライブのサイズ

300 GB

NIC 数 2NIC 速度 1 ギガビット

認証 Windows 基本ロード バランサーの種類 ハードウェア負荷分散

ソフトウェア バージョン SharePoint Server 2010 ( プレリリース バージョン)ローカルで実行されるサービス

サーバーの全体管理

Microsoft SharePoint Foundation Incoming E-MailMicrosoft SharePoint Foundation Web ApplicationMicrosoft SharePoint Foundation Workflow Timer Service

データベース サーバー

データベース サーバー DB 1-2

プロセッサ 4 クアッドコア 3.19 GHzRAM 16 GBオペレーティング システム Windows Server 2008、64 ビット

ストレージ 15 ディスク (各 300 GB、15,000 RPM)

NIC 数 2NIC 速度 1認証 NTLMソフトウェア バージョン SQL Server 2008

データ セット実際の WCM 展開と共通の特性を持つデータ セットを使用してテストを行いました。負荷は一定ですが、さまざまなページを要求しました。

オブジェクト 発行サイト

コンテンツ データベースのサイズ

2.63 GB

コンテンツ データベースの数 1サイト コレクションの数 1Web アプリケーションの数 1サイトの数 50ページ数 20,000 ページ (1,000 ペー

ジずつ 20 フォルダーに分割)ページの構成 2 つの画像への参照を含む基

本的な HTML 記事ページ

ページ サイズ 未圧縮状態で 42 KB、圧縮状態で 12 KB

画像 3,000 (それぞれば 30 KB ～ 1.3 MB)

動的にファイルを圧縮する既定の設定ではなく、常にファイルを圧縮するようにインターネット インフォメーション サービス (IIS) を構成することをお勧めします。動的な圧縮を有効にした場合、IIS は、CPU 利用率が所定のしきい値を超えるまでページを圧縮し、その時点で、CPU 使用率がしきい値より低くなるまでページの圧縮を停止します。このホワイト ペーパーのテストは、常に圧縮をオンにして行いました。

このテストのデータ セットは、既定の SharePoint 機能を追加設定なしで使用しました。実際のサイトでは、この基本機能がカスタマイズされていることが多いため、実際のソリューションでテストを行うことが重要です。