SharePoint Server 2010 の Web コンテンツ管理でパフォーマンスおよび容量要件を見積もる
適用先: SharePoint Server 2010
トピックの最終更新日: 2016-11-30
この記事には、発行インフラストラクチャを有効にした Microsoft SharePoint Server 2010 サイトに関連する容量管理のガイダンスが含まれます。ここで説明される情報は、SharePoint Server 2010 のみに適用され、SharePoint Foundation には適用されません。
この記事では、以下のシナリオについて説明します。
インターネット発行サイト - 企業のプレゼンス サイト。
この種のサイトはインターネットに発行され、匿名のインターネット ユーザーが会社の情報を検索できるようにします。このようなサイトは、ブランド設定され、コンテンツが厳密に管理されています。
イントラネット発行サイト - 内部ニュース サイト。
この種のサイトは、組織で内部的に発行されます。主な用途は、組織内の認証されたユーザーと情報を共有することです。このサイトの情報は、厳密に管理されることもありますが、一部の領域では管理は緩やかです。
エンタープライズ Wiki - ナレッジ リポジトリ。
エンタープライズ Wiki は、寄稿者が新しいページを作成し、(もしあれば) その他のページにそれらをリンクすることで、組織的に成長していく単一ファーム サイトです。エンタープライズ Wiki は一般的には組織内部で発行されます。このサイトは、SharePoint 環境により統合され機能強化されたソリューションを使用することで、企業または組織全体のユーザーが知識を得て、共有できるようにします。
この文書では、以下の概念について説明します。
多数の読み取り操作に対応できるように最大化する必要がある重要な測定基準 (スループット)。
Web コンテンツ管理 SharePoint Server 2010 展開に関連するさまざまなボトルネックの可能性。
スループットを最大化できるようにする、出力キャッシュの重要性。
エンド ユーザーの読み取りエクスペリエンスに対する、書き込み操作の影響。
この記事の内容
前提条件
テストの詳細および手法
Web コンテンツ管理の展開
最適化する対象
テスト結果と推奨事項
執筆者について
前提条件
この文書を読む前に、SharePoint Server 2010 における容量管理の基本的な考え方を必ず理解しておいてください。以下の文書は、容量管理への推奨手法と、この文書の情報を効率的に活用する際に役立つコンテキストを説明します。
この記事でのデータのコンテキストの理解に役立つ、パフォーマンスと容量のより概念的な情報については、以下の文書を参照してください。
Capacity management and sizing for SharePoint Server 2010 (英語)
Performance and capacity technical case studies (SharePoint Server 2010) (英語)
テストの詳細および手法
各テストにおいて、現実の状況で存在する可能性がある変数は、特定の推奨事項について説明する目的で抽象化されています。従って、予測される要求ボリュームに対応できるように適切に規模設定し、自分の環境でテストし監視することが非常に重要です。容量管理の概念についての詳細は、「SharePoint Server 2010 での容量管理と規模設定の概要」を参照してください。
この記事は、サイト コレクション機能、SharePoint Server 発行インフラストラクチャ、および出力キャッシュでのパフォーマンスについて説明します。これらの機能は、SharePoint Server 発行インフラストラクチャが有効である場合にのみ使用できます。既定では、発行ポータルにおけるこの機能は有効にされています。
データセット
テストは、実際の Web コンテンツ管理展開と特性を共有するデータセットを使用して実施されました。負荷は一定でしたが、さまざまなページが要求されました。以下の表は、これらのテストで使用されたデータセットについて説明します。
データセット
| オブジェクト | 発行サイト |
|---|---|
コンテンツ データベースのサイズ |
2.63 GB |
コンテンツ データベースの数 |
1 |
サイト コレクションの数 |
1 |
Web アプリケーションの数 |
1 |
サイトの数 |
50 |
ページの数 |
20,000 ページ。それぞれ 1,000 ページを含む 20 のフォルダーに分割 |
ページの構成 |
2 つの画像を含む、基本的な HTML での記事ページ |
ページ サイズ |
非圧縮時に 42 KB、圧縮時に 12 KB |
画像 |
30 KB から 1.3 MB の範囲で 3,000 個 |
インターネット インフォメーション サービス (IIS) では、既定の設定で動的にファイルを圧縮する代わりに、ファイルを常に圧縮するように構成することを推奨します。動的圧縮が有効な場合、CPU 利用率があるしきい値を超えるまで、IIS はページを圧縮しますが、その後、利用率がそのしきい値を下回るまで、ページを圧縮しなくなります。この記事でのテストは、圧縮を常に有効にして実施されました。
このテストのデータセットでは、製品に含まれる既定の SharePoint Server 2010 機能だけを使用しました。実際のサイトでは、これらの基本的な機能に加えて、その他のカスタマイズが追加されることがあります。従って、実際のソリューションのパフォーマンスをテストすることが重要です。
ハードウェア
ファーム内の Web サーバーの数は、テストにより異なります。しかし、すべて同一のハードウェアが使用されました。以下の表は、これらのテストで使用された Web およびアプリケーション サーバーのハードウェアについて説明します。
アプリケーション サーバーと Web サーバーのハードウェア仕様
| Web サーバー | |
|---|---|
プロセッサ |
2 クアッド コア、2.33 GHz |
RAM |
8 GB |
オペレーティング システム |
Windows Server 2008、64 ビット |
SharePoint のドライブのサイズ |
300 GB |
ネットワーク アダプターの数 |
2 |
ネットワーク アダプターの速度 |
1 ギガビット |
認証 |
Windows 基本 |
負荷分散の種類 |
ハードウェア負荷分散 |
ソフトウェアのバージョン |
SharePoint Server 2010 (プレリリース版) |
ローカルで実行されているサービス |
サーバーの全体管理 Microsoft SharePoint Foundation 受信電子メール Microsoft SharePoint Foundation Web アプリケーション Microsoft SharePoint Foundation Workflow Timer Service |
以下の表は、これらのテストで使用されたデータベース サーバーのハードウェアについて説明します。
データベース サーバーのハードウェア仕様
| データベース サーバー | |
|---|---|
プロセッサ |
4 クアッド コア、3.19 GHz |
RAM |
16 GB |
オペレーティング システム |
Windows Server 2008、64 ビット |
記憶域 |
300 GB のディスク 15 台、15,000 RPM |
ネットワーク アダプターの数 |
2 |
ネットワーク アダプターの速度 |
1 ギガビット |
認証 |
NTLM |
ソフトウェアのバージョン |
Microsoft SQL Server 2008 |
用語集
この文書では、いくつかの専門的な用語が使用されています。以下は、重要な用語とその定義です。
RPS 秒あたりの要求。1 秒間にファームまたはサーバーが受信した要求の数。これはサーバーおよびファームの負荷の一般的な計測基準です。
要求は、ページ負荷とは異なる点に注意してください。各ページには複数のコンポーネントが含まれ、それらは、ページが読み込まれるときに 1 つまたは複数の要求を作成するからです。従って、1 つのページ負荷では複数の要求が作成されます。一般的には、認証チェックと、重要ではないリソースを使用するイベントは、RPS 計測でカウントされません。
グリーン ゾーン これは、サーバーが以下の一連の要件を維持することができる状態です。
要求の少なくとも 75 % でのサーバー側待機時間が 1 秒以下。
すべてのサーバーでの CPU 利用率が 50 % 以下。
障害発生率が 0.01 % 以下。
Web コンテンツ管理の展開
サーバー ファーム トポロジの選択に影響する、SharePoint 発行サイトでコンテンツが制作される方法には、2 つのモデルがあります。
一括作成モデルでは、単一のサイト コレクションが作成者と閲覧者で共有されます。作成者は、いつでもコンテンツを作成、更新することができ、これにより時間帯によって読み取りおよび書き込み操作の分布は変化します。一般的に、このサーバー ファームでは、多くの読み取りと中程度の書き込みが発生します。
以下の図は、トポロジの観点から、一括作成が機能する方法について説明します。
.gif "一括作成環境を示す図")
コンテンツ展開モデルでは、複数のサイト コレクションが個別に、また排他的にコンテンツの作成および発行をサポートします。コンテンツは、作成環境で作成、更新され、その後、閲覧者が読めるように一定のスケジュールで公開環境に展開されます。コンテンツが作成環境から展開されている場合以外、公開環境は主に読み取り要求に応えます。一括作成モデルと異なり、コンテンツ展開へのサーバー負荷はスケジュール設定された間隔に調整することができます。
以下の図は、トポロジの観点から、コンテンツ展開が機能する方法について説明します。
.gif "コンテンツ展開環境を示す図")
これらのコンテンツ作成モデルは相互に排他的です。
インターネット発行サイトとイントラネット発行サイトは、一括作成モデルまたはコンテンツ展開モデルのどちらかを使用することができますが、エンタープライズ Wiki は一括作成モデルで最適に機能します。より多くの比率のユーザーがページを編集できることから、エンタープライズ Wiki では、一般的には読み取り操作に比べて大量の書き込み操作が発生します。エンタープライズ Wiki ページは記事ページの発行と違い、異なるパフォーマンス特性を示します。
最適化する対象
このセクションは、Web コンテンツ管理環境を最適化する情報について説明します。環境の最適化には、スループット、ボトルネック、およびキャッシュを管理する方法を理解する必要があります。
このセクションの内容
スループットは重要な測定基準
ボトルネックと修復
キャッシュの有効性
スループットは重要な測定基準
SharePoint Server 2010 Web コンテンツ管理展開の容量計画をするとき、スループットと応答時間は最適化する必要がある最も重要な測定基準です。スループットは、サーバー ファームが毎秒実行することができる操作の数で、1 秒あたりの要求 (RPS) で測定されます。
ボトルネックと修復
ボトルネックとは、もし枯渇すると、サーバー ファームがそれ以上の要求を提供できなくなるシステム リソースです。以下の図は、ボトルネックになる可能性があり、監視する必要がある、サーバー ファームの要素とリソースについて説明します。
.gif "サーバー ファームの構成ブロックを示す図")
Web サーバーの CPU 利用率
Web サーバー CPU は、最も簡単に規模調整できるコンポーネントなので、よく調整されたトポロジのボトルネックになることがあります。ロード バランサーは、Web サーバー間で要求をルーティングして、1 台のサーバーだけがその他のサーバーより極端に使用されないようにします。
Web サーバー CPU 利用率が最大になった後も、その他のユーザーがサイトを表示することはできますが、これらのユーザーへのサーバー応答時間は長くかかるようになります。この動作は、要求ボリュームのスパイクの管理に役立ちます。しかし、サーバー ファームの容量を超える持続的な負荷は、最終的には要求待機のしきい値を超えるほど大きな要求のバックログを発生させます。この場合、Web サーバーが要求を調整し、HTTP エラー 503 で応答します。以下の図では、要求待機しきい値に達した後で、HTTP エラーだけを返していることにより、サーバー応答時間は減少しています。
.gif "応答時間対リソース使用率を示す図")
以下の変化がこの図に示されています。
Web サーバー CPU 利用率が 100 % に近づくにつれて、応答時間は増加します。
要求待機しきい値を超えた以後の要求には、エラーが返されます。
その他のボトルネック
Web サーバー CPU がボトルネックではない場合は、次にボトルネックがないか調査するアイテムは、ファーム トポロジ、ファーム構成、またはサービスを提供しているページのコンテンツです。これらの要素で発生する可能性があるボトルネックには、以下のものが含まれます。
ネットワーク 高スループットの状況では、ネットワークは、Web サーバーとデータベース サーバーの間か、Web サーバーとエンド ユーザーの間で飽和している可能性があります。この状況を回避する目的で、Web サーバーでデュアル ギガビット ネットワーク アダプターを使用することを推奨します。
データベース サーバー CPU データベース サーバー CPU がボトルネックになっている場合は、サーバー ファームに Web サーバーを追加しても、ファームの最大スループットを向上することはできません。ボトルネックが Web サーバー CPU ではなく、データベース CPU にあるということは、2 つの状況が原因である可能性があります。
キャッシュ設定の問題、または (特に出力キャッシュされていない) 非常に遅いページ。この場合、データベース サーバー CPU の利用率が高く、スループットが低いか中程度、また Web サーバー利用率が低いか中程度になります。
データベース サーバーがファームで必要なスループットの容量に達した可能性があります。この場合、高いスループットで、Web サーバーおよびデータベース サーバー CPU の利用率が高くなる特徴があります。
キャッシュの有効性
SharePoint Server 2010 は 3 種類のキャッシュを使用します。これらのキャッシュの共通の目的は、頻繁に要求されるデータについてデータベースへの呼び出しを減らすことによって、効率を向上することです。ページへのそれ以降の要求には、Web サーバーのキャッシュから応えることにより、Web サーバーおよびデータベース サーバーでのリソース利用率を大きく減らすことができます。
3 つの種類のキャッシュは、以下のとおりです。
出力キャッシュ このキャッシュは、Web サーバーのメモリに要求されたページ コンテンツを保存します。出力キャッシュの詳細については、「出力キャッシュとキャッシュ プロファイル」(https://go.microsoft.com/fwlink/?linkid=121543&clcid=0x411) を参照してください。
オブジェクト キャッシュ このキャッシュは、Web サーバーのメモリに、Web およびリスト アイテム メタデータのような SharePoint オブジェクトを保存します。オブジェクト キャッシュの詳細については、「オブジェクト キャッシュ」(https://go.microsoft.com/fwlink/?linkid=123948&clcid=0x411) を参照してください。
バイナリ ラージ オブジェクト (BLOB) のディスクベースのキャッシュ このキャッシュは、ディスクに画像、サウンド、ビデオ ファイルとその他のラージ バイナリ ファイルを保存します。BLOB キャッシュの詳細については、「バイナリ ラージ オブジェクトのディスクベースのキャッシュ」(https://go.microsoft.com/fwlink/?linkid=123947&clcid=0x411) を参照してください。
これらのキャッシュは、どれも高スループットの持続にとって重要です。しかし、出力キャッシュが最も大きい影響を持っており、この記事全体で詳細に説明されています。
テスト結果と推奨事項
このセクションは、テストされた特定の領域について説明し、それらのテストから得られた推奨事項を示します。
このセクションの内容
出力キャッシュを有効にすることの影響
匿名ユーザーと認証されたユーザー
読み取りおよび書き込み操作のスケール アウト特性
出力キャッシュでの注意事項
CPU および応答時間への読み取りボリュームの影響
書き込み操作の全体への影響
コンテンツ展開の影響
コンテンツ展開エクスポート中のデータベース スナップショットの影響
コンテンツ特性
出力キャッシュを有効にすることの影響
出力キャッシュは、SharePoint Server 2010 ソリューションを多くの読み取り操作に最適化する目的で役立つ機能です。
これらのテストでは、最大 RPS を確認する目的で、データベース サーバーまたは Web サーバーの CPU 利用率が 100 % に達してボトルネックになるまで、ファームに要求をしているアクティブ ユーザーの数が追加されました。テストは、さまざまな出力キャッシュのヒット率において Web サーバーのスケール アウトの影響を示し、1x1 (1 台の Web サーバーと 1 台のデータベース サーバー)、2x1、4x1、および 8x1 ファーム トポロジで実施されました。
出力キャッシュのヒット率
出力キャッシュのヒット率とは、出力キャッシュの、ミスに対するヒットの測定です。
キャッシュ ヒットは、すでにキャッシュに保存されているオブジェクト データに対する要求が受信されたときに発生します。
キャッシュ ミスは、キャッシュに保存されていないオブジェクト データの要求が受信されたときに発生します。キャッシュ ミスが発生したとき、それ以後のそのデータへの要求でキャッシュ ヒットが発生するように、キャッシュは要求されたオブジェクトデータの保存を試行します。
ページ要求でキャッシュ ミスを発生させる原因はいくつかあります。
出力キャッシュを使用しないように構成されたページ。
パーソナライズされたページのように、現在のユーザーに固有のデータを持つページ。
出力キャッシュのバリエーション キーでの初回の参照。
キャッシュされたコンテンツが期限切れになった後の初回の参照。
以下の図は、1 台から 4 台の Web サーバーと 1 台のデータベース サーバーを組み合わせたファームにおいて、ピーク スループットでの出力キャッシュの影響について説明します。
.gif "ピーク時における出力キャッシュの効果を示す図")
注意
100 % 出力キャッシュ ヒット率の 4x1 サーバー ファームで、最大 RPS のデータ要素は、推定された結果であり、実際に計測された結果ではありません。サーバー ファーム要求ボリュームは、データ転送率は毎秒 1 ギガビットに近づき、ネットワーク帯域幅の限界に達しました。どの場合でも、Web サーバー CPU 利用率は 100 % です。
以下の表は、1 台から 4 台の Web サーバーと 1 台のデータベース サーバーを組み合わせたファーム トポロジにおける、出力キャッシュ ヒット率の影響について説明します。
さまざまなファーム トポロジへの出力キャッシュ ヒット率の影響
| 出力キャッシュのヒット率 | 測定 | 1x1 | 2x1 | 4x1 | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
100 % |
|
|
|
|
||||||||
95 % |
|
|
|
|
||||||||
90 % |
|
|
|
|
||||||||
50 % |
|
|
|
|
||||||||
0% |
|
|
|
|
出力キャッシュを有効にすることの影響についての結論および推奨事項
より高い出力キャッシュ ヒット率は、最大 RPS を大幅に増加させます。従って、SharePoint Server 2010 発行ソリューションを最適化する目的で、出力キャッシュを有効にすることを推奨します。サイト コレクションの [出力キャッシュの設定] ページで出力キャッシュを構成することができます。詳細については、Office.Microsoft.com Web サイトの「サイト コレクションでページ出力キャッシュ設定を構成する」(https://go.microsoft.com/fwlink/?linkid=205058&clcid=0x411) を参照してください。
出力キャッシュを有効にしたテストでは、ページをキャッシュした最初の要求は除外されました。つまり、ページの一部はキャッシュにすでに保存されていました。ユーザーがキャッシュされていないページを始めて要求したとき、ページはキャッシュに追加されます。キャッシュが容量の限界に達するか、限界に近づくと、キャッシュは最も古い時点で要求されたデータを削除します。
0 % のキャッシュ ヒット率は、有効にされた出力キャッシュが、1 度、消去された後で、環境において再びいっぱいになっていく短い時間をシミュレートします。たとえば、これは現実の環境で、毎日、アプリケーション プールがリサイクルされるときに発生します。アプリケーション プール リサイクルと、次の要求およびページのキャッシュ間の短い時間で 0 % のキャッシュ ヒット率が存在する状況に対応できるように、ハードウェアを適切にスケール アップ、またはスケール アウトすることが重要です。また、0 % のキャッシュ ヒット率は、出力キャッシュが無効の環境をシミュレートします。
匿名ユーザーと認証されたユーザー
前のテストでは、サイトへのすべての要求が匿名の読者によって行われることを想定しています。しかし、サイトで、一部またはすべてのユーザーが認証される場合があります。認証された読者のシナリオの例には、企業のイントラネット発行サイトや、メンバーのみのコンテンツがあるインターネット上のサイトがあります。
出力キャッシュ プロファイルで、認証されたユーザーに、匿名ユーザーに対する動作とは異なる出力キャッシュ動作を指定することができます。
キャッシュ プロファイル
キャッシュ プロファイルは、ページ、ページ アイテム、コンテンツ タイプ、およびサイト展開での各規模のレベルに適用できる設定を統合します。キャッシュ プロファイルは、以下の種類のキャッシュ動作を定義します。
アイテムがキャッシュに保留される必要がある時間の長さ。
セキュリティ トリミング ポリシー。
期間や変更のような、設定の期限切れ。
ユーザー権限、ユーザーの権利、およびその他のカスタムの変数に基づく、さまざまなキャッシュされたコンテンツ。
キャッシュ プロファイルへのあらゆる変更は、サイトのすべての該当するコンテンツにすぐに反映されます。匿名ユーザーと認証されたユーザーに、異なるキャッシュ プロファイルを設定することができます。
匿名ユーザーには、パブリック インターネット (匿名専用) 出力キャッシュ プロファイルが、認証されたユーザーには、エクストラネット (発行済みサイト) 出力キャッシュ プロファイルが使用されます。
以下のグラフは、認証されたスループットのデータベース サーバー CPU 利用率への影響を示します。
.gif "認証されたスループットの効果を示す図")
認証モデルは Windows の基本認証でした。インターネット サイトで Windows 基本認証を使用することは推奨されませんが、この認証方式は、認証にかかる最小のオーバーヘッドを示す目的で選択されました。このオーバーヘッドの程度は、使用する特定の認証メカニズムによって変化します。展開をテストするときは、認証メカニズムの影響を考慮するようにしてください。SharePoint Server 2010 でサポートされる認証メカニズムの詳細については、「認証方法を計画する (SharePoint Server 2010)」を参照してください。
匿名ユーザーと認証されたユーザーについての結論と推奨事項
資格情報を確認する追加の処理がデータベースサーバーに負荷を加えることにより、認証されたユーザーは、RPS が低く、スケール アウトの効果が小さいと感じます。テスト結果に示されるように、ユーザーが認証されるときの最大 RPS は、匿名でのファームへのアクセスより大幅に低くなります。
読み取りおよび書き込み操作のスケール アウト特性
このテストは、時間ごとに書き込みを記録するように作成されました。この記事での書き込みとは、新しい発行ページの作成およびチェックイン、または既存の発行ページの編集およびチェックインと定義されます。
以下のテストでは、Web サーバー CPU 利用率が約 80 % から 90 % に達するまで、読者がシステムに追加され、次に人工的な遅延を使用して、環境での書き込み操作が実行されました。テストでの、毎時間の合計の書き込みは約 500 回でした。すべてのテストで 90 % の出力キャッシュ ヒット率を使用しました。1x1、2x1、および 4x1 ファームで同じテストを行い、各構成で全体的な読み取りスループットと Web サーバーおよび SQL Server の CPU 利用状況を調べました。さらに、ベースラインとして匿名の読み取り専用構成をテストし、Windows 基本認証を使用して認証された読者での構成もテストしました。
読み取り専用スケール アウトのテスト中に Web サーバー CPU は 100 % の利用状況にされましたが、書き込みでのスケール アウトのテストでは Web サーバー CPU は 80 % から 90 % の間が維持されました。これは、書き込み処理が行われるとき、さらなる CPU 利用の余地を残す目的で行われました。
以下のグラフは、各テスト中に調べられた、全体的な読み取り RPS を示します。書き込み動作がある場合でも、Web サーバーが追加されることで、読み取り RPS は直線的に増加します。しかし、書き込みが発生する場合は、RPS の損失があります。
.gif "読み取り/書き込み操作のスケール アウトを示す図")
Web サーバーの数が増えるに従って、データベース サーバー CPU の利用状況は増大します。以下のグラフは、さまざまな構成での SQL Server の CPU 利用状況の成長パターンを示します。この記事の「匿名ユーザーと認証されたユーザー」セクションで示したように、認証はデータベース サーバーの CPU 利用率に影響し、これは (やはりデータベース サーバー CPU 利用率に影響する) 書き込み動作が追加されるとより顕著になります。
.gif "読み取り/書き込み負荷が DB サーバーに与える影響を示す図")
SQL Server の利用状況で推定された傾向は、認証された読み取り要求を持つ 6 台の Web サーバーで SQL Server がボトルネックになることを示しています。しかし、匿名の読み取りの場合は、Web サーバーを増やしてスケール アウトすることができます。
一般的な展開に要因を追加することが、データベース サーバーの負荷に影響することを理解することは重要です。また、容量計画をしているときに、これらの要因を考慮することが重要です。一般的なデータベース サーバー CPU 利用率のグリーン ゾーンを確認する方法の詳細については、「SharePoint Server 2010 での容量管理と規模設定の概要」を参照してください。
読み取りおよび書き込み操作のスケール アウト特性についての結論および推奨事項
データベース サーバーがボトルネックにならない場合は、Web サーバーの数を増やしてスケール アウトすることはスループットを上げる効率的な戦略であることが、データによって示されています。匿名の読み取り/認証された書き込みの組み合わせのテストは、匿名の読み取り/書き込みがない組み合わせのテストと比較して、平均で Web サーバー CPU 利用率が 52 % 向上しています。さらに、認証された読み取りでは、各要求が SQL Server へのラウンド トリップを必要とするさらなる認証チェックを受けることにより、大きな SQL Server 負荷が加わります。
以下のグラフは、スループットのデータベース サーバー CPU 利用率への影響を示します。
.gif "スループットが DB サーバーの CPU に与える影響を示す図")
出力キャッシュでの注意事項
容量計画での唯一の関心事が RPS を最大化することであれば、これらのテストの最適なキャッシュ ヒット率は 100 % となります。しかし、データ鮮度の要件またはメモリの制約により、一部またはすべてのページで出力キャッシュを有効にすることが不可能または不必要であることがあります。
データ鮮度
出力キャッシュから返されたデータに、元のコンテンツに変更を加えた新しい更新が含まれていないことがあります。コンテンツ展開シナリオ、または (認証された作成者の) 運用作成シナリオのソースで、既存のコンテンツを更新した直後に、作成者が最新の変更を確認する必要がある場合があります。
これは、通常、キャッシュ プロファイルの、[期間] プロパティを設定することで改善されます。これは、期限切れになるまでの、キャッシュされたページが出力キャッシュに保持される期間を指定します。ページが期限切れになったとき、キャッシュから削除されます。以後の要求はキャッシュ ミスとなり、その結果、ページ コンテンツが更新されます。
また、キャッシュ プロファイルの [変更を確認する] プロパティを設定することもできます。これにより、サーバーは、ページがキャッシュされた時間と、サイト コレクションでコンテンツが最後に変更された時間を比較します。一致しないタイム スタンプを持つページの要求がされると、サイト コレクションのすべてのページでキャッシュが無効化されます。[変更を確認する] プロパティはサイト コレクションのすべてのページに影響することから、あまり更新されず、基本的に静的な、認証された一括作成ソリューションがある場合にのみ、このオプションを有効にすることを推奨します。このオプションを長い期間と組み合わせることにより、サイトに更新が行われるまで、すべてのページがキャッシュから返されるようにできます。
既定では、[変更を確認する] プロパティは無効です。これは、元の ASPX ページが変更されたかどうかにかかわらず、Web サーバーが、まだ期限切れになっていないページへの要求に応答するときに、出力キャッシュからデータを返すことを意味します。
1x1 サーバー ファームで実施されたこのテストでは、[変更を確認する] プロパティ以外のすべての変数は、「読み取りおよび書き込み操作のスケール アウト特性」セクションのテストと同じです。[変更を確認する] プロパティが有効のとき、キャッシュはより頻繁に消去され、その結果、出力キャッシュ ヒット率は下がります。
以下のグラフは、スループットに対する、[変更を確認する] プロパティの影響を示します。
.gif "変更の確認の効果を示す図")
特定の場合を除いて、出力キャッシュ プロファイルの [変更を確認する] プロパティは有効にしないことを推奨します。一括作成モデルを使用しており、コンテンツがあまり変更されないサイトでは、あわせて長いキャッシュ期間を設定することで、認証されたユーザーに対しては、この設定が役立つ可能性があります。しかし、その他の種類のサイトでは、RPS が低下する可能性が高くなります。
要件によっては、即座に、または既定の設定より速くライブになる必要がある、速度が重要なコンテンツが必要となることがあります。この場合は、期間を減らすか、出力キャッシュを有効にしないでください。
出力キャッシュでの注意事項についての結論と推奨事項
出力キャッシュは、容量管理に関するすべての問題を解決するわけではありません。出力キャッシュが不適切な状況がいくつかあり、出力キャッシュを有効にして出力キャッシュ プロファイルを構成するときに、これらを考慮する必要があります。
CPU および応答時間への読み取りボリュームの影響
このテストは、匿名アクセスおよび出力キャッシュを有効にした 1x1 ファームで実施されました。
以下のグラフは、CPU および応答時間への読み取りボリュームの影響を示します。
.gif "読み取りが CPU と応答時間に与える影響を示す図")
CPU および応答時間への読み取りボリュームの影響についての結論と推奨事項
「ボトルネックと修復」セクションで示したように、CPU が完全に使用されるほど十分な要求ボリュームを Web サーバーが受信するまで、サーバー応答時間は、通常、一定の状態のままです。Web サーバーで CPU が完全に使用されると、応答時間は大幅に増加します。しかし、サーバー ファームは、まだ、追加の要求ボリュームを処理することができます。
書き込み操作の全体への影響
これらのテストで、作成操作と編集操作の比率は、均等に配分されました。毎時間 500 ページ以上を作成または編集することは、ほとんどの SharePoint 展開の動作の範囲外であることから、毎時間の書き込みの値は最大約 500 でテストされました。テストには、「コンテンツ展開の影響」セクションで説明した、コンテンツ展開のような自動化された過程は含まれませんでした。これらの作成および編集操作では、複数の SQL Server 操作を発生させることがあります。従って、これらのテストで測定された書き込みは SQL Server のレベルではなく、ユーザーが書き込み操作とみなす操作であることに注意してください。すべての毎時間での書き込み RPS のテストは、1x1 ファームで実施されました。
テストでは、まず、トラフィック スパイクのバッファーを残せるように、Web サーバーの CPU 使用率を 60% から 80 % の間になるまで読み取り操作を追加し、テスト全体でこの平均の利用率レベルを維持しました。次に書き込みを導入し、人工的な遅延を使用して、書き込み操作の数を制御しました。しかし、書き込みが発生した間に、Web サーバーおよび SQL Server の CPU 利用状況が増加するスパイクがありました。以下のグラフのように、一部のキャッシュ ヒット率のスパイクは、通常の処理のしきい値を超えましたが、平均は通常の処理の範囲に留まりました。
.gif "書き込み操作がスループットに与える影響を示す図")
前のグラフに示されるように、書き込みが環境に追加されるにつれて、スループットの限定的な減少がありました。グラフは、読み取り専用シナリオと、毎時間約 500 の書き込み中の読み取り操作の間のスループットの変化を示します。各出力キャッシュ ヒット率について 2 つのデータ要素が記録されました。従って、データ要素の関係は必ずしも直線的ではありません。
以下のグラフに示すように、割合の減少は、より低いキャッシュ ヒット率でより顕著です。全体的な読み取り RPS は、書き込みにかかわらず、主にキャッシュ ヒット率に依存しています。
.gif "ボリュームの書き込みに起因するスループットの低下を示す図")
以下のグラフは、書き込みがシステムに追加されたとき、データベース サーバーの CPU 利用率があまり増加しなかったことを示しています。縦軸は CPU 容量の 0 % から 10 % であることに注意してください。
.gif "平均な DB サーバーの CPU 対 WPH を示す図")
予想どおり、書き込み操作中には追加の SQL Server 負荷がありました。しかし、最も大きい増加でも 2.06 % で、それほど重要ではありません。平均のデータベース サーバー CPU 利用率は、すべてのテストの全体で、10 % 以下でした。このテストは、1x1 ファームで行われました。Web サーバーの数が増やされてスケール アウトされるにつれて、データベース サーバーの CPU 利用状況は増加します。これは「読み取りおよび書き込み操作のスケール アウト特性」でより詳しく説明されています。
テスト中に、Web サーバー CPU 利用率も測定されました。以下のグラフでは、毎時間の書き込みは 500 に近づいたにもかかわらず、Web サーバー CPU 利用状況の平均は、テスト全体で 60 % から 80 % の範囲だったことを示しています。
.gif "Web サーバーの CPU 使用率対 WPH を示す図")
しかし、以下のグラフに示すように、実際に測定された CPU 利用率では、書き込みが発生するときにスパイクが発生しています。一般的には、これらの CPU スパイクは、問題にはなりません。グリーン ゾーンの目的は、CPU 負荷のスパイクを吸収する CPU の余力を用意することです。また、Web サーバーが追加されると、スパイクの影響はこれらのサーバーに分散され、単一の Web サーバー CPU への影響は減ります。しかし、このようなスパイクを実際の展開で予期しておく必要があります。通常、書き込み操作は爆発的に発生しますが、均等に分散して発生することはありません。
.gif "書き込みとの関連で Web サーバーの CPU 使用率を示す図")
90 % のキャッシュ ヒット率は、一般的な展開としては非常に低いといえます。多くの読み取り操作がある、ほとんどの SharePoint Server 2010 展開では、95 % 以上の出力キャッシュ ヒット率になります。
スループットにおける書き込み操作の影響についての結論と推奨事項
テストのデータでは、書き込み操作が、システムの全体的なスループットに大規模な悪影響を及ぼさないことを読者に対して示しています。しかし、書き込み操作が CPU 利用状況のスパイクをもたらすことがあることに注意し、これらのスパイクを予想して一般的な構成を計画する必要があります。これらのスパイクを緩和する戦略は、複数の Web サーバーにスケール アウトすることです。これには 2 つの利点があります。
複数の Web サーバーに書き込み負荷を分散して、全体的なスパイクを軽減します。
特に高い出力キャッシュ ヒット率で、読み取り RPS が向上します。
コンテンツ展開の影響
編集と閲覧に単一の環境を使用する一括作成モデルの代わりに、単一の環境を、作成環境と運用環境の 2 つの個別の環境に分割し、コンテンツ展開を使用して、作成環境から運用環境にコンテンツをコピーすることができます。
この構成では、コンテンツ展開がコンテンツをインポートするとき以外、運用環境での書き込み操作は限定的か、まったく発生しません。これらのテストでは、Web サーバーの CPU 利用状況が 70 % から 80 % の範囲になるまで、読み取りが追加されました。次に、コンテンツ展開ジョブは、作成サイト コレクションからそれぞれ 500 ページを含む 10 のサイトをパッケージとしてエクスポートして、発行サイト コレクションにこのパッケージをインポートしました。テスト結果を確認できるようにコンテンツ展開ジョブの期間を十分に延長する目的で、展開されたパッケージのサイズは実際の一般的な環境より大規模にしています。展開されたコンテンツの特性の詳細については、「データセット」セクションを参照してください。
エクスポートが完了した後で、個別のサイト コレクションにコンテンツをインポートし、そのインポートの進行中に、アプリケーション サーバーおよび SQL Server の負荷とスループットを測定しました。インポート テストは、いくつかの異なる出力キャッシュ ヒット率について実施されました。
ここで得られた重要な結果は、以下のグラフに示すように、インポートでは全体的な読み取り RPS について、限定的な影響しかないということです。また、以下の表に示すように、キャッシュのヒット率にかかわらず、インポートは、Web サーバー CPU 利用率に重大な影響を及ぼしませんでした。しかし、以下のグラフに示すように SQL Server CPU に関しては、顕著な影響がありました。コンテンツのインポート中にデータベース サーバーには負荷が発生することから、このことは予想されていました。しかし、インポート中でも、SQL Server CPU の利用状況は、テストされたすべてのキャッシュ ヒット率で 12 % 以下でした。
.gif "コンテンツ展開のインポートの効果を示す図")
以下の表は、コンテンツ展開インポートの Web サーバーおよびデータベース サーバー CPU 利用率への影響を示します。
コンテンツ展開インポートの Web サーバー CPU 利用率への影響
| キャッシュ ヒット | 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 利用率への影響
| キャッシュ ヒット | 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 つの書き込み (ソース データベースと、各データベース スナップショットに 1 つずつ) を発生させることを意味します。
作成環境へのスナップショットの影響を確認する目的で、書き込み操作も発生しているエクスポート操作中に、書き込み RPS、応答時間と、Web サーバー、データベース サーバー、およびアプリケーション サーバーの CPU 利用率を計測しました。以下の表が、その結果を示します。
コンテンツ展開中のデータベース スナップショットの影響
| 測定基準 | 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 % |
コンテンツ展開エクスポート中のデータベース スナップショットの影響についての結論と推奨事項
テストの結果では、データベース スナップショットでのあらゆる測定されたデータ要素について、重大な影響はみられませんでした。記録されたすべての相違は、エラーの範囲内でした。これはデータベース スナップショットが、パフォーマンスへの重大な影響なしに使用できることを示しています。
コンテンツ特性
テストは、一連の特定の質問に回答するように作成された単一のデータセットで実施されました。実際のデータセットはさまざまで、また時間の経過に伴い変化します。このセクションは、ページ ライブラリ内のページの数やページに含まれる機能のようなコンテンツ特性が、容量管理についての判断にどのように影響するかを説明します。
ページの数
さまざまなページ ライブラリのサイズでの最大 RPS がテストされました。このテストは、出力キャッシュを無効にした 4x1 トポロジで匿名アクセスについて実施されました。すべてのページは非圧縮時に 42 KB、圧縮時に 12 KB でした。以下の表が、テスト結果を示します。
RPS へのライブラリ ページ カウントの影響
| ページの数 | 3 | 1,000 | 20,000 |
|---|---|---|---|
最大 RPS |
860 |
801 |
790 |
ページ数を 20,000 ページに上げても、最大 RPS に重大な影響はありませんでした。
複数値のルックアップ フィールド
複数値のルックアップ フィールドは、企業の管理されたメタデータを使用する列のような、別のリスト内の 1 つまたは複数のアイテムを参照するリスト内の列です。これらのフィールドは、通常、ページでの検索キーワードとして使用され、必ずしも表示されません。エンタープライズ Wiki のように、場合によっては、ページのコンテンツにこれらのフィールド値を表示する意味があることもあります。たとえば、ページが作成されたときに (ニュースサイトでの、各国のニュース、裏話、スポーツのような) カテゴリに分類されることがあります。そしてマスター ページには、ユーザーがページのどのカテゴリにタグを付けたかを示すプレースホルダーが含まれます。
複数値のルックアップ フィールドでは、ページが要求されるたびに、取得されるデータが増えます。従って、1 ページに多くの複数値のルックアップ フィールドがあると、パフォーマンスに影響することがあります。
以下のグラフは、複数値のルックアップ フィールドがスループットに与える影響を示します。
.gif "複数値検索フィールドの効果を示す図")
以下のグラフは、複数値のルックアップ フィールドがファーム リソース利用率に与える影響を示します。
.gif "複数値検索のリソース効果を示す図")
複数値のルックアップ フィールドの数が増加するにつれて、Web サーバーとデータベース サーバー間のネットワークに与える影響により、最大 RPS が低下します。
利用状況レポートの影響
利用状況レポートは、管理者がサイトの利用状況の統計を監視する際に役立つサービスです。利用状況レポートの詳細については、「Usage and Health data collection を構成する (SharePoint Server 2010)」を参照してください。
1x1 ファームで最大 RPS の利用状況レポート タイマー ジョブの影響をテストしました。次の表は、その結果を示しています。
利用状況ログ記録のパフォーマンスへの影響 (RPS での)
| 利用状況 DB が有効 | 利用状況 DB が無効 | 違い | |
|---|---|---|---|
出力キャッシュが有効 |
3,459 |
3,463 |
4 |
出力キャッシュが無効 |
629 |
638 |
9 |
結果は、読み取り専用シナリオでは、利用状況ログ記録を有効にしても RPS には大きく影響しないことを示しています。
執筆者について
Joshua Stickler は、Microsoft での SharePoint Server 2010 のプログラム マネージャーです。
Tyler Butler は、Microsoft での SharePoint Server 2010 のプログラム マネージャーです。
Zhi Liu は、Microsoft での SharePoint Server 2010 のテストのソフトウェア開発エンジニアです。
Cheuk Dong は、Microsoft での SharePoint Server 2010 のテストのソフトウェア開発エンジニアです。
Philippe Flamm は、Microsoft での SharePoint Server 2010 のテストのソフトウェア開発エンジニアです。