Web コンテンツ管理の容量とパフォーマンスを見積もる (SharePoint Server 2013)
適用対象:
2016 2019 Subscription Edition SharePoint in Microsoft 365
SharePoint Server 2013 は、匿名ユーザーがアクセスするインターネット サイトや、認証されたユーザーがアクセスするイントラネット サイトにコンテンツを発行するために多くの企業で使用されています。 この記事では、SharePoint Server 2013 でコンテンツを発行して Web コンテンツを管理するために必要なコンピューターの数や種類を計画する際に役立つ容量およびパフォーマンスのデータを紹介します。
SharePoint では、さまざまな種類のサイトを発行することができ、使用可能な発行手段もサイトによってさまざまです。 SharePoint Server 2013 の発行機能は、ブランド設定されたインターネット、イントラネット、およびエクストラネット サイトの作成を支援するように設計されています。 SharePoint Server 2013 の発行の詳細については、「 SharePoint Server のインターネット、イントラネット、エクストラネット サイトへの発行の概要」を参照してください。
概要
この記事では以下のようなシナリオについて説明します。
インターネット プレゼンス サイト
顧客、パートナー、投資家、および就職希望者に対して情報を提供します。 匿名のインターネット ユーザーが企業について情報を調べるために利用します。 通常、このようなサイトにはブランドが設定され、コンテンツは企業によって厳密に管理されます。
インターネット ビジネス サイト
企業が顧客に提供する製品やサービスを宣伝するサイト。 自社製品のカタログを表示できます。
イントラネット サイト
ある会社は、組織内でこのサイトを内部的に発行します。 これらのサイトは、認証されたユーザーと企業の情報を共有し、サイトを厳しく管理してアクセスを制限するか、すべての jnternal ユーザーに公開します。
エクストラネット サイト
遠隔地の従業員、パートナー、および顧客を対象にしたコンテンツへのアクセスを提供するサイト。 記事の分類用のメタデータ付きで作成されたコンテンツを提供するナレッジ ベースにアクセスできるようにします。 ユーザーは、トラブルシューティングやサポートに関する記事を検索して閲覧できます。
これらのシナリオで "クロスサイト コレクションの発行" や "コンテンツ検索 Web パーツ" を使用すると、サイト コレクション間でコンテンツを再利用できます。 これらの機能は、どのように容量を計画するかに影響を与えます。 詳細については、「 SharePoint Server でのクロスサイト発行の概要」を参照してください。
注:
この記事では、"クロス サイト コレクションの発行" を "クロスサイト発行" と呼ぶことにします。
SharePoint Server 2013 の管理ナビゲーションにより、発行サイトに分類型のナビゲーションを導入できます。 詳細については、「SharePoint Server の管理ナビゲーションの概要」を参照してください。
この記事では、容量およびパフォーマンスのデータを次の 2 つのパートに分けて説明します。 最初のパートでは、新しいクロスサイト発行の手法と管理ナビゲーションを取り上げます。 2 番目のパートでは、作成者一括モデルを使用します。
注:
この記事で解説するシナリオは、クロスサイト発行のサイトと作成者一括のサイトのどちらを使用しても実現できます。 クロスサイト発行および管理ナビゲーションの機能は、相互に依存することはなく、独立して使用できます。
この記事で使用するモデルでは、以下の 3 つの主要な指標を紹介します。
スループット
サイトが対応できる 1 秒あたりのページ ビューの数。
サーバーの応答時間
サーバーが要求を処理するために必要とする時間で、これにより、ユーザーにページが表示されるまでの時間が決まります。 この記事で紹介するサーバーの応答時間は、95 パーセンタイル値と 50 パーセンタイル値です。 この 2 つの値はそれぞれ、要求の 95% および 50% が、提示されている時間より速いという意味です。 これらの値は、特定の要求について SharePoint 利用状況データベースに "時間" として記録される値を使って計測しました。
コンテンツの鮮度
更新されたアイテムが検索結果に反映されるまでの時間。クロスサイト発行のシナリオを検討する際に、良い指標となります。
この記事のシナリオでは、以下の 2 つの状態を使用します。
グリーン ゾーン
サーバーの使用率が 60% 未満。 これは、サーバー稼働中のほとんどの時間で目標となる数値です。
レッド ゾーン
サーバーがフル稼働に近づいている状態。 これは、SharePoint サイトに通常より多くの負荷が掛っている状態と考えられます。 レッド ゾーンでは、ユーザーからの要求に応答しようとしてサーバーの応答時間が長くなり始めます。
前提条件に関する情報
この記事を読むには、SharePoint Server 2013 による容量管理の主要な概念を理解している必要があります。 以下に挙げる記事は、容量管理のための推奨されている手法を説明しており、この記事の情報を十分に活用するために役立ちます。
なお、発行シナリオに影響を与えるいくつかの新機能は、この記事で取り上げていないことに注意してください。 たとえば、デバイス チャネル、SEO 最適化、表示テンプレート、およびクエリ ルールなどです。 さらに、クロスサイト発行サイトの機能と構成についても、この記事では詳しく説明していません。 詳細については、「 SharePoint Server でのクロスサイト発行の計画」および「SharePoint Server でWeb コンテンツ管理ソリューションを構成する」を参照してください。
この記事のデータを理解するのに役立つ容量とパフォーマンスの詳細については、「 SharePoint Server 2013 でのパフォーマンス計画」を参照してください。
管理ナビゲーションを使用したクロスサイト発行
このセクションでは、匿名ユーザー向けのクロスサイト発行と、作成者一括発行という 2 つの分野のテスト データを紹介します。
匿名ユーザー向けのクロスサイト発行
このセクションに掲載したテスト結果は、容量計画のガイダンスを提供する目的で設定した基本的なクロスサイト発行サイト モデルに基づいています。 匿名ユーザーがアクセスする Web サイトについて SharePoint による展開を計画する際は、このガイダンスを実際の展開の詳細に応じて調整したうえで使用してください。
このテスト ケースでは、クロスサイト発行の機能を使用します。 カタログとしてマークされた複数のサイト コレクション コンテンツを提供した後、SharePoint Search Service アプリケーションによるクロールを実行します。 コンテンツ検索 Web パーツなどの検索テクノロジを使用した Web パーツと、カタログ アイテムを再利用する Web パーツを利用して、別のサイトのページにコンテンツを表示します。 詳細については、「 SharePoint Server でのクロスサイト発行の概要」を参照してください。
クロスサイト発行をテストするために作成したモデル サイトには、以下のような特徴があります。
およそ 500 万ページまたはアイテムを持つ Web サイトを発行します。
アイテムは約 1,000 のカテゴリに関連付けられています。
コンテンツは、1 つまたは複数のカタログに含まれて他のサイト コレクションに配置されます。
Web サイトでは、アイテムが関連付けられたカテゴリにリンクする管理ナビゲーションを使用します。
このリストで後述するベースライン展開トポロジでは、Web サイトの 1 秒あたりの平均ページ ビューは最大で 80 ページです。 ピーク時には、1 秒あたり 100 ページ ビューに上がります。 このスループット数を拡張するには、トポロジにコンピューターを追加します。 このスループット数を縮小するには、トポロジからコンピューターを除去します。
検索クローラーは、カタログに対するクロールを 1 分間隔で連続実行し、1 秒あたり 5 件の更新を検出します。
Web サイトは、以下のようなページおよびトラフィック パターンを持ちます。
ホーム ページには 3 つのコンテンツ検索 Web パーツと、1 つの絞り込みパネル Web パーツがあり、トラフィックの 15% をこれらのパーツから受け取ります。
カテゴリ ページには、3 つのコンテンツ検索 Web パーツ、1 つの分類絞り込みパネル Web パーツ、1 つの検索結果絞り込みパネル Web パーツがあり、トラフィックの 45% をこれらの Web パーツから受け取ります。
カタログ アイテム ページには 1 つのカタログ アイテム再利用 Web パーツと、2 つのコンテンツ検索 Web パーツがあり、トラフィックの 40% をこれらの Web パーツから受け取ります。
それぞれのコンテンツ検索 Web パーツとカタログ アイテム再利用 Web パーツは、同期クエリを発行します。
カタログ アイテム ページでは、受け取るトラフィック量が少ないため、匿名検索の結果キャッシュを使用しません。
ファームでは、フロントエンド Web サーバーとして稼働しているコンピューターに対して、バイナリ ラージ オブジェクト (BLOB) キャッシュを有効にします。
このシナリオをテストするために使用したサーバー トポロジは、下図のとおりです。
図 1: テスト用のサーバー トポロジ
SharePoint で使用されるすべてのデータベース用の SQL Server をホストする 1 台のコンピューター
SharePoint サービス アプリケーション、分散キャッシュ サービス、検索分析処理、および検索管理の役割をホストする 1 台のコンピューター
検索クローラーおよびコンテンツ処理 (CPC) の役割をホストする 1 台のコンピューター
検索インデックス ノードのクエリ処理をホストし、フロントエンド Web サーバーとして機能する 3 台のコンピューター
注:
このテストで使用したコンピューターは、Windows Server 2008 R2 を実行する物理コンピューターです。 仮想マシンおよび Windows Server 2012 の使用方法に関する推奨事項については、検索容量の計画と、「SharePoint Server 2013 の容量計画」を参照してください。
重要
今回のテスト ラボのトポロジは、検索主導型の発行シナリオ用に最適化したものです。 この構成は、グループ作業型の SharePoint 展開の場合と異なります。 たとえば、今回の構成では、高いパフォーマンスを実現する目的でフロントエンド Web サーバーを検索インデックス サーバーとして利用しています。 > テスト ラボ トポロジでは、アプリケーション サーバーをホストするコンピューターの使用率が低いことが学習されました。 そのため、分散キャッシュ サービスを専用サーバー上に配置するのではなく、このアプリケーション サーバー上に配置しました。 分散キャッシュ サービスを専用サーバー上でホストするかどうかは、実際の環境に応じて決定して構いません。 ただし、高いパフォーマンスを得るためには、検索インデックス サーバーの役割を持つフロントエンド Web サーバーで分散キャッシュ サービスをホストすることはお勧めしません。
テスト ラボからのレポート
テスト ラボでは、図 1 のトポロジで構成した物理コンピューターを使用し、Visual Studio Team System (VSTS) のロード テストを行いました。 詳細については、「DevOps とアプリケーション ライフサイクル管理」を参照してください。 テスト コンピューターの技術仕様を以下の表に記載します。
注:
ブラウザー キャッシュや、画像または JavaScript ファイルなどの依存する要求は使いませんでした。 実際に発生する依存する要求の量は、発行サイトをどのようにカスタマイズするかによってかなり大きく変動することがあります。 > テストで使用したページでは、約 50 ページの読み込み時間 1 (PLT1) 要求の種類 (空のブラウザー キャッシュ) と、PLT2 要求の種類 (ブラウザー キャッシュからの結果を含む後続の要求) に対して約 3 つの要求が行われました。 通常は、SharePoint BLOB キャッシュからこれらのアイテムの要求にデータが提供されますが、今回のパフォーマンス値と大きく異なることはありません。
| サーバー コンポーネント | SharePoint Server を実行しているサーバー |
|---|---|
| プロセッサ | Intel Xeon CPU @2.27 GHz (2 個のプロセッサ、合計 8 個のコア、合計 16 個のスレッド) |
| RAM | 24 GB |
| オペレーティング システム | Windows Server 2008 R2 Enterprise SP1、64 ビット |
| SharePoint ドライブのサイズ | 内部ディスク上の 200 GB |
| インデックス検索に使用するストレージ | 外部ディスク アレイ上の 78 GB (2 x Dell PERC H700 SCSI) |
| ネットワーク アダプター数 | 2 |
| ネットワーク アダプターの速度 | 1 ギガビット |
| 認証 | なし - 匿名 |
| ソフトウェアのバージョン | SharePoint Server 2013 |
| サーバー コンポーネント | データベース サーバー |
|---|---|
| プロセッサ | Intel Xeon CPUs L5520 @2.27GHz (2 個のプロセッサ、合計 8 個のコア、合計 16 個のスレッド |
| RAM | 24 GB |
| オペレーティング システム | Windows Server 2008 R2 Enterprise SP1、64 ビット |
| ディスク アレイ | 2 x Dell H700 SCSI |
| ネットワーク アダプター数 | 2 |
| ネットワーク アダプターの速度 | 1 ギガビット |
| 認証 | NTLM |
| ソフトウェアのバージョン | Microsoft SQL Server 2008 R2 SP1 |
10 分間実行した結果は次のとおりです。
| テスト項目 | グリーン ゾーン | レッド ゾーン |
|---|---|---|
| VSTS ユーザー数 (ユーザーの同時実行をシミュレート): | 60 | 100 |
| サーバーの応答時間の 50 パーセンタイル値*: | 219 ミリ秒 | 302 ミリ秒 |
| サーバーの応答時間の 95 パーセンタイル値*: | 412 ミリ秒 | 635 ミリ秒 |
| 1 秒あたりのページ ビュー数: | 78 | 98 |
これは検索インデックスからのコンテンツを表示するクロスサイト発行シナリオです。 興味深い点として、検索クエリをホストするサーバーから提供されたクエリ数や、匿名結果キャッシュが利用されたクエリ数を調べてみました。 このモデルでは、クエリの 60% で匿名結果キャッシュが利用されています。 匿名結果キャッシュについては、この記事で後ほど説明します。
| テスト項目 | グリーン ゾーン | レッド ゾーン |
|---|---|---|
| 1 秒あたりのクエリの合計数: | 235 | 294 |
| 匿名結果キャッシュから提供されたクエリの数: | 145 | 182 |
| 検索が行われたクエリの数: | 90 | 112 |
テストの実行中に対象のコンピューターが示した平均 CPU 使用率とピーク時のメモリ使用量の値は、以下の通りです。
| テスト項目 | グリーン ゾーン | レッド ゾーン |
|---|---|---|
| 平均 CPU (フロントエンド Web サーバー当たりの検索インデックス ノード) | 59% | 80% |
| 平均 CPU (アプリケーション サーバー。分散キャッシュを含む) | 8% | 9% |
| 平均 CPU (検索 CPC ノード) | 5% | 5% |
| 平均 CPU (SQL Server) | 未計測 | 未計測 |
| ピーク時のメモリ使用量 (フロントエンド Web サーバー当たりの検索インデックス ノード) | 7.5 GB | 7.5 GB |
| ピーク時のメモリ使用量 (アプリケーション サーバー。分散キャッシュを含む) | 10.1 GB | 10 GB |
| ピーク時のメモリ使用量 (CPC 検索ノード) | 6.5 GB | 6.5 GB |
なお、サーバーの通常の使用時にはさまざまなタイマー ジョブが実行されるため、実際のメモリ使用量は若干異なる可能性があります。 今回の調査では、負荷をかけて 2 週間のテスト実行をした後、インデックス/フロントエンド Web サーバー ノードのメモリ使用量は 12 GB でした。
クロスサイト発行ページに検索 Web パーツのコンテンツが表示される仕組み
コンテンツ検索 Web パーツなどの検索 Web パーツが発行ページに含まれている場合、ブラウザーは検索クエリが完了する前にページの処理を開始します。 これにより、ページの認識される待機時間が向上します。 検索クエリが完了すると、クエリの完全な結果がブラウザーに送信され、ブラウザーへの接続が閉じられます。 ユーザーは、検索結果が非同期的に読み込まれると考える場合があります。 ただし、ページが要求されている間も、クエリはサーバーから発行されます。
コンテンツ検索 Web パーツには、これとは別に非同期モードがありますので、注意してください。このモードでは、クエリはページのロードが完了した後にブラウザーからデータを受け取ります。
クロスサイト発行サイトにおける負荷の変化の影響
負荷テストでは、使用する VSTS ユーザーの数 (サイトに同時にアクセスするユーザー数に似たもの) を変えながら調査しました。 次のグラフに、負荷の増加に伴うサーバーの応答時間の増加を示します。 サーバーの応答時間は 750 ミリ秒以下に抑え、ユーザーが SharePoint 展開で応答性の高いエクスペリエンスを得るようにすることをお勧めします。
図 2: 負荷を変えた場合のスループットおよびサーバー応答時間の変化を示すグラフ
クロスサイト発行サイトのスケール アウト
SharePoint 展開で実際に想定されるトラフィックが前述のベースライン ケースより多い場合や、少ない場合には、インデックスおよびフロントエンド Web サーバーの役割を実行するファーム上のコンピューター数を、トラフィックの量に応じて変えることができます。 次のグラフは、同じクロスサイト発行サイトについて、負荷パターンを変え、インデックス ノードのフロントエンド Web サーバーとして使用するコンピューターの数を変えた場合のスケール アウトの結果を、インデックス ノードのフロントエンド Web サーバーとなるコンピューターが 1 台から 6 台までの場合を示しています。
図 3: 展開のスケール アウト
それぞれの構成の場合に、サーバーの応答時間が、前のセクションで説明したベースライン値と同等になるように負荷を調整しました。
注目できるのは、コンピューターの数が増えるほどトポロジの複雑さが増して、台数の増加のメリットを相殺し始めることです。 追加されたコンピューターそれぞれのスループットは、既に環境に組み込まれているコンピューターのスループットを下回ります。 これらの数値は、スケール アウトのパターンを示すために提供したものであり、実際のパフォーマンスは、SharePoint 展開をどのように構築するかによって異なります。
サイト計画のガイドライン
今回のパフォーマンス テストの大部分は、これまでのセクションで説明した展開を使用して実施しました。 以下のリストに記載するガイドラインは、実際の展開がテスト ラボと異なる場合に適切な容量計画を行うために利用してください。
検索インデックス内のアイテム数が増えるほど、一般的に待ち時間が長くなります。 各インデックス パーティションには、最大 1,000 万個のアイテムを格納できます。 標準的な Web サイトでは、表示するアイテム数が 1,000 万個を超えることはほとんどありません。 したがって、これまでに説明したトポロジでは、1 つのパーティションだけで必要を満たせます。 複数のインデックス パーティションが必要になるのは、1,000 万個を超えるアイテムをホストする場合か、多数の小さくて高速なインデックス パーティションを利用したい場合です。 複数のインデックス パーティションを使用する場合は、「 SharePoint Server でインターネット サイトの検索をスケーリングして、 検索トポロジのサイズを正しく設定する」を参照してください。
ページ (またはページ レイアウト) にコントロールや Web パーツを追加するほど、そのページに対するサーバーの応答時間にある程度のオーバーヘッドが加算されます。
1 つのページに 5 つを超える同期的なコンテンツ検索 Web パーツまたはカタログ アイテム再利用 Web パーツを使用することは避けてください。 1 つのページに対する要求を処理する際に、SharePoint Server 2013 は最大 5 つまでのクエリを同時に実行して結果を返します。 1 つのページに 5 つを超えるクエリが存在すると、SharePoint Server 2013 は最初の 5 つのクエリが完了してから、次の 5 つのクエリの実行を開始します。 5 つを超えるコンテンツ検索 Web パーツまたはカタログ アイテム再利用パーツを必要とするページがある場合は、追加のコンテンツ検索 Web パーツを非同期モードで実行するか、クエリ ルールと結果ブロックを使用することができます。
コンテンツ検索 Web パーツとカタログ アイテム再利用 Web パーツには、非同期モードがあります。 Web パーツに関連付けられたクエリは、ブラウザーがページをロードした後に実行されます。 クエリが低速な場合は、このモードを利用して残りのページを早くユーザーに表示するようにできます。 そうでない場合は、同期クエリを使用して最良のページ ロード時間を提供することをお勧めします。
検索結果の絞り込みパネルで絞り込み条件が多いと、クエリの処理時間が長くなります。 管理プロパティに表示する絞り込み条件の数は、変更することができます。 詳細については、「SharePoint Server で絞り込み条件とファセット ナビゲーションを構成する」を参照してください。
ナビゲーション ノードの階層が深い場合に分類絞り込みパネル Web パーツを使用すると、クエリの処理時間が増加します。 配下に 200 個を超えるナビゲーション ノードがあるページでは、分類絞り込みパネル Web パーツを使用しないことをお勧めします。 ナビゲーションノードの数が多いと、サーバーの応答時間が低下してスループットが減少することがあります。
高い可用性を備えた SharePoint 展開を設計する必要がある場合は、以下のものを追加してください。
既存のコンピューターが使用不能になった場合に、分散キャッシュの役割でサービス アプリケーションを実行する追加のコンピューター。
インデックス ノードを実行している 1 つまたは複数のフロントエンド Web サーバーが使用不能になった場合に、負荷を受け持つ追加のコンピューター。
CPC の役割を持つコンピューターが使用不能になった場合に、サイト内の更新を引き続き反映するために CPC の役割を引き継ぐ追加のコンピューター。
データベース サーバーの 1 つが使用不能になった場合に、データベース クエリに引き続きデータを提供するための SQL Server トポロジ。
検索クロールの速度とコンテンツの鮮度
今回のテストでは、発行中のカタログ コンテンツを更新する処理についてもテストを実施しました。 そのために、更新したアイテムが発行サイトに反映されるまでの経過時間を計測しました。 実験では、カタログに対して 1 秒あたり 5 つの更新を行い、カタログに対する連続クロールを 1 分間隔に設定しました。 変更内容が発行サイトに反映されるまでの平均時間は約 2 分でした。 最短時間は 1 分弱、最長時間は 3 分でした。 CPC の役割を実行するコンピューターの数を増やしても、これらの数値に大きな変化は見られませんでした。
しかし、カタログのフル クロールについては、CPC の役割を実行するコンピューターの数が増えるほど、1 秒間に処理されるアイテム数が増加しました。 次のグラフは、1 秒間に処理されるアイテム数と、CPC の役割を持つファーム内のコンピューター数の関係を示しています。 このテスト データが、ベースライン テストに使用したものではない SharePoint 展開から得られたことに注目できます。 CPC ノードを追加するほどフル クロールの回数が改善されたため、この知見は SharePoint 展開に当てはまるはずです。
図 4: コンテンツ処理 (CPC) コンピューターの数がフル クロールに与える効果
したがって、カタログに対するフル クロールを高速に行う必要がある場合には、実際の展開の中で CPC の役割に使用するコンピューターの数を増やすことができます。
管理メタデータ サービス アプリケーションに対する負荷
今回のテストでは、管理ナビゲーションを使用するサイトに関連する発行シナリオで、管理メタデータ サービス アプリケーションに対する顕著なメモリ要件や CPU 要件がないことが分かりました。 この記事で前述した展開の場合、管理メタデータ サービス アプリケーションは、他の SharePoint サービス アプリケーションを実行しているコンピューター上で実行できます。 管理ナビゲーション機能は、サイトへの最初の要求を受け取った時点で、サービス アプリケーションに対する 1 つの接続を作成します。 後続の要求では、フロントエンド Web サーバーがキャッシュしている値が使用されます。 したがって、フロントエンド Web サービスが要求に応答して処理を行っている間、管理メタデータ サービス アプリケーションには負荷がかかりません。
匿名検索の結果キャッシュ
匿名検索の結果キャッシュには、クエリの結果、クエリの絞り込みデータ、および SharePoint 分散キャッシュ サービスから返される追加の結果テーブルが格納されます。 キャッシュの各項目は、結果の並べ替え順序、要求された絞り込み条件、動的な並べ替えルールなど、クエリのパラメーターに依存しています。 キャッシュは、検索 Web パーツや CSOM クライアントからのクエリなど、Web アプリケーションが処理するすべてのクエリに効果を与えます。 詳細については、「SharePoint Server での検索アーキテクチャの概要」および「SharePoint Server でのインターネット サイトのスケール検索」を参照してください。
セキュリティ上の問題により、認証されたクエリにキャッシュは使用されません。
好ましい結果を得るには、分散キャッシュ サービスを、SharePoint サービス アプリケーションが実行されているコンピューター上でのみ実行するように構成することをお勧めします。 分散キャッシュ サービスは、フロントエンド Web サービスの役割を持つコンピューター上で実行するべきではありません。
匿名検索の結果キャッシュに含まれるアイテムは、既定では 15 分間隔で更新されます。 Microsoft PowerShell を使用して、キャッシュが構成されている Web アプリケーションでキャッシュ期間を構成できます。
$webapp.Properties["SearchResultsCacheTTL"] = <number of seconds to keep in cache>
$webapp.Update()
検索結果の更新間隔を既定値より短くするには、この値を小さく設定します。 この場合、検索サービスがデータを提供する必要のあるクエリ数が増えることに注意してください。
トラフィック量が特に多い発行ページには、常にキャッシュを使用することをお勧めします。 たとえば、サイトのホーム ページや、検索 Web パーツを使用するカテゴリ ページがそれに該当します。 カタログ アイテムのページをキャッシュに入れることはお勧めしません。 個々のカタログ アイテムのページはホーム ページに比べてアクセスの頻度が低く、アイテムをキャッシュに入れても無駄になる可能性が高いからです。
匿名検索の結果キャッシュをオフにした場合、今回のテスト環境では、同じ負荷パターンに対してサーバーの応答時間が著しく増加し、1 秒あたりのページ ビュー数 (スループット) も低下しました。 この関係を次のグラフに示します。
図 5: 匿名検索の結果キャッシュの効果
既定では、コンテンツ検索 Web パーツは匿名検索結果キャッシュを使用するように構成されています。 Catalog-Item カタログ アイテム ページで使用される Web パーツの再利用は、これらのページが一般的に示すスパース アクセス パターンのため、Web パーツを使用するように構成されていません。
匿名検索結果キャッシュを使用する (または使用しない) 個々の Web パーツのキャッシュ動作を構成するには、Web パーツの DataProviderJSON プロパティでサブプロパティ "TryCache" の値を設定します。 この値が "true" の場合は、キャッシュが使用されます。 この値が "false" の場合は、匿名検索クエリのキャッシュがクエリで使用されなくなります。
出力キャッシュの効果
出力キャッシュは、SharePoint Server 2013 の発行シナリオで負荷を軽減するための効果的な方法です。 この記事の出力キャッシュが動作する仕組みについて詳しくは、「出力キャッシュとキャッシュ プロファイル」を参照してください。
SharePoint 展開では、SharePoint コンテンツ データベースおよび検索サービス アプリケーションに対する負荷を軽減するうえで、出力キャッシュの利点を活用できる可能性があります。 たとえば、以下のような状況が該当します。
一部のページが多数のトラフィックを受け取っている。
SharePoint コンテンツ データベースが多数のトラフィックを受け取っている。
検索クエリを処理するコンピューターの CPU 使用率が高い。
出力キャッシュを使用する対象として推奨されるのは、サイトのホーム ページや最上位レベルのカテゴリ ページ、大量のトラフィックを受け取っている特定のアイテム ページなど、サイト上で特に人気の高いページです。
重要
SharePoint Server 2013 では、出力キャッシュを有効にしたページでコンテンツ検索 Web パーツも使用した場合に、既知の問題があります。 使用している展開の中でこの問題を回避するには、「SharePoint Server 2013 の更新プログラムの説明: 2013 年 3 月 12日」で更新プログラムをインストールしてください。
次のグラフは、テスト環境から得られた結果の中から、サイト トラフィックの 60% を受け取っているホーム ページおよびカテゴリ ページで出力キャッシュを使用した場合の結果を示しています。
図6: ホーム ページおよびカテゴリ ページに対する出力キャッシュの効果
注:
コンテンツ検索 Web パーツには、非同期モードで実行するための設定があります。 出力キャッシュは、非同期のコンテンツ検索 Web パーツからの負荷には適用されません。
利用状況の分析処理
利用状況の分析情報を提供するために、SharePoint Server 2013 は利用状況データベースにある情報を処理します。 今回のトポロジでは、検索管理ノード、分散キャッシュ サービス、およびその他のサービス アプリケーションを含むノード上で、分析処理を行いました。 詳細については、「SharePoint Server での分析処理の概要」を参照してください。
今回、最初のほうのテストで使用したクロスサイト発行サイトを使用して、分析処理時間の計測をいくつか行いました。 計測したのは、サイト内のページで発生した大量のクリック イベントの処理に SharePoint Server 2013 が要した時間です。 この結果はクロスサイト発行サイトから得られたものですが、作成者一括発行の手法を使用したサイトにも当てはまります。
利用状況分析の処理をテストするため、以下のような模擬的なイベントを、1 週間にわたって毎日発生させました。
40 万人のユーザーが、2,750 万回のクリック イベントを、300 万個のリスト アイテムにわたって発生させた。
Zipf 分析を利用して、一部のアイテムおよびユーザーが多数のイベントに関与し、残りのアイテムおよびユーザーは少しのイベントにしか関与しないようにした。
これは、1 日に合計 750 万個のイベントが生成され、さまざまなユーザーがさまざまなトラフィック パターンでサイトにアクセスした状況に相当します。
この分析を 7 回起動して、1 週間のトラフィックをシミュレートしました。 利用状況分析を毎日実行し、6 日間にわたってデータを蓄積しました。 その後、時間を計測し、7 日目に至ります。 7 日目は、丸 1 週間のアイテムを処理し、関係グラフを更新するので、処理に最も時間がかかるはずです。 また、8 日目の実行時間とディスク使用量は、1 日目と似ているはずです。
この分析処理がそれを実行したコンピューターに顕著な影響を与えることはなく、引き続きクエリを正常に処理し、検索主体のサイトでコンテンツの鮮度を保持することができました。
結果を次の表にまとめます。
| テスト スケジュール | 関係グラフの更新 | 実行時間 (時間) | ピーク時の合計ディスク使用量 | 利用状況分析のピーク時のディスク使用量 |
|---|---|---|---|---|
| 1 日目 | いいえ | 02:35 | 2.65 GB | |
| 2 日目 | No | 02:43 | ||
| 3 日目 | No | 03:23 | ||
| 4 日目 | No | 04:39 | ||
| 5 日目 | No | 06:08 | ||
| 6 日目 | No | 07:35 | ||
| 7 日目 | Yes | 08:29 | 82.4 GB | 4 GB |
次のグラフに、それぞれの日の実行時間を示します。
図 7: 1 日の実行時間 (時間)
認証されたユーザー向けのクロスサイト発行
SharePoint による発行は、イントラネット サイトでも一般に利用されています。 SharePoint Server 2013 を使用することにより、イントラネット サイトでもクロスサイト発行の利点を活用できます。 この後のセクションでは、認証されたユーザーが利用するクロスサイト発行サイトを計画する際に検討するべきいくつかの重要な相違点について説明します。 それらの例外を除いて、匿名でアクセスするサイトに適用される規則は、認証されたユーザーがアクセスするサイトにも適用されます。
匿名検索の結果キャッシュがない
少し前のセクション「匿名検索の結果キャッシュ」で説明したとおり、このキャッシュは SharePoint サイトに匿名でアクセスするユーザーにのみ効果を発揮します。 匿名検索の結果キャッシュを使用して匿名でアクセスされるサイトと比べると、認証されたユーザーによってアクセスされるサイトのスループット容量はかなり低くなります。 標準的なイントラネット サイトで、前のセクションで紹介した負荷 (1 秒あたり最大で 100 ページ ビュー) を処理できるものはほとんどありません。 とはいえ、これは検討に値する重要な相違点です。
このようなシナリオでは、出力キャッシュを使用すれば、匿名検索の結果キャッシュがないことに伴うデメリットをある程度軽減できます。 1 秒あたりのページ ビューの数が多くなると想定されるクロスサイト発行サイトでは、出力キャッシュを有効にすることを検討してください。
重要
コンテンツ検索 Web パーツには、それを有効にすると Web パーツが非同期モードで実行されるようになる設定があります。 そのような非同期のコンテンツ検索 Web パーツに出力キャッシュは適用されません。
大規模な検索インデックス
SharePoint Server 2013 を展開する企業の規模によっては、SharePoint Server 2013 のイントラネット展開でインデックスを作成するドキュメントの数が多くなることがあります。 その場合、ドキュメントのインデックスを作成するために、前のセクションで説明したトポロジとは異なる検索トポロジが必要になります。 SharePoint 展開のサイズを適切に設定するには、「 SharePoint Server での検索の計画 」を参照してください。
作成者一括発行
このセクションでは、SharePoint Server 2013 を使用するガイダンスと結果を示しますが、容量計画に影響を与えるさまざまな機能については詳しく説明しません。 この領域の詳細については、「 SharePoint Server での Web コンテンツ管理」を参照してください。
匿名ユーザーに対する作成者一括発行
今回のテストでは、以下のような特徴を持つ Web サイトを対象にしました。
最大 20,000 件の記事のページを、それぞれ 1,000 ページのフォルダー 20 個に分割し、1 サイト コレクション内の 50 のサイトに配置します。
構造化ナビゲーションを使用します。
概して少なくとも 1 秒あたり 50～100 ページ ビューを受け取ります。
トラフィック パターンには、以下のようなページが混在します。
それぞれ 1 つのコンテンツ クエリ Web パーツを含む 20 のページから、さまざまなスコープのコンテンツ データベース クエリが発行されます (トラフィックの 20%)。
それぞれ複数のコンテンツ クエリ Web パーツを含む 30 のページから、さまざまなスコープのコンテンツ データベース クエリが発行されます (トラフィックの 30%)。
40 KB のテキストおよび 2 つの画像で構成される 1,600 件の記事が、トラフィックの 50% を受け取ります。
推奨されるサーバーのトポロジを次の図に示します。
図 8: 作成者一括発行のテスト用トポロジ
SQL Server をホストする 1 台のコンピューター
フロント エンド Web サーバーとして SharePoint サービス アプリケーションをホストする 1 台のコンピューター
テスト ラボの結果
テスト ラボでは、物理コンピューターを使用して前の図に示したトポロジを組み、Visual Studio Team System の負荷テストを実施しました。
次の表に、テストに使用したコンピューターの技術仕様を示します。
| サーバー コンポーネント | SharePoint サーバー |
|---|---|
| プロセッサ | Intel Xeon CPU @2.33GHz (2 個のプロセッサ、合計 8 個のコア、合計 8 個のスレッド) |
| RAM | 24 GB |
| オペレーティング システム | Windows Server 2008 R2 Enterprise、64 ビット |
| ネットワーク アダプター数 | 2 |
| ネットワーク アダプターの速度 | 1 Gbps |
| 認証 | なし - 匿名 |
| ロード バランサーの種類 | Windows ソフトウェアのロード バランサー |
| ソフトウェアのバージョン | SharePoint Server 2013 |
| サーバー コンポーネント | データベース サーバー |
|---|---|
| プロセッサ | Intel Xeon CPU MP7130M @2.79GHz (2 個のプロセッサ、8 個のコア、16 個のスレッド |
| RAM | 16 GB |
| オペレーティング システム | Windows Server 2008 R2 Enterprise、64 ビット |
| ディスク アレイ | 2 x Dell PERC 5/E |
| ネットワーク アダプター数 | 1 |
| ネットワーク アダプターの速度 | 1 ギガビット (Gbps) |
| 認証 | NTLM |
| ソフトウェアのバージョン | Microsoft SQL Server 2008 R2 SP1 |
次の表に、10 分間実行したときの結果を示します。
| テスト項目 | グリーン ゾーン | レッド ゾーン |
|---|---|---|
| VSTS ユーザー数: | 5 | 15 |
| Server Response Time 50th percentile: | 69 ミリ秒 | 112 ミリ秒 |
| Server Response Time 95th percentile: | 92 ミリ秒 | 221 ミリ秒 |
| 1 秒あたりのページ ビュー数: | 57 | 93 |
| 平均 CPU (アプリケーション サーバーとフロントエンド Web サーバー) | 55 | 97 |
| 平均 CPU (SQL Server) | 7 | 9 |
| ピーク時のメモリ使用量 (アプリケーション サーバーとフロントエンド Web サーバー) | 8.9 GB | 8.9 GB |
出力キャッシュの効果
出力キャッシュは、SharePoint Server 2013 の発行シナリオで負荷を軽減するための効果的な方法です。 詳細については、「SharePoint Server でのキャッシュとパフォーマンスを計画する」を参照してください。
次の表に、出力キャッシュを有効にして 90% のヒット率で 10 分間実行した場合の結果を示します。
| テスト項目 | グリーン ゾーン | レッド ゾーン |
|---|---|---|
| VSTS ユーザー数: | 5 | 15 |
| Server Response Time 50th percentile: | 2 ミリ秒 | 2 ミリ秒 |
| Server Response Time 95th percentile: | 74 ミリ秒 | 88 ミリ秒 |
| 1 秒あたりのページ ビュー数: | 190 | 418 |
| 平均 CPU (アプリケーション サーバーとフロントエンド Web サーバー) | 58 | 85 |
| 平均 CPU (SQL Server) | 5 | 7 |
| ピーク時のメモリ使用量 (アプリケーション サーバーとフロントエンド Web サーバー) | 9.2 GB | 9.4 GB |
このテスト結果は、出力キャッシュを使用すると SharePoint 発行サイトのスループットが著しく増加し、サーバーの応答時間が短縮されることを示しています。 要求に対して出力キャッシュから提供された場合、応答時間はほとんど瞬時です。
次のグラフにこのテスト結果の概要を示します。
図 9: キャッシュ ヒット率 90% の場合の出力キャッシュの効果
管理ナビゲーションの効果
SharePoint Server 2013 では、発行サイトに管理ナビゲーションを使用することもできます。 これを設定する方法の詳細については、「 SharePoint Server での管理ナビゲーションの概要」を参照してください。
管理ナビゲーションを使用した場合のテストは、構造化ナビゲーションのテストと同じ条件で実施しました。 テストの結果として、サイトで管理ナビゲーションを使用した場合と構造化ナビゲーションを使用した場合とで、大きな差は見られなかったことが分かります。
| テスト項目 | グリーン ゾーン | レッド ゾーン |
|---|---|---|
| VSTS ユーザー数: | 5 | 15 |
| Server Response Time 50th percentile: | 70 ミリ秒 | 111 ミリ秒 |
| Server Response Time 95th percentile: | 95 ミリ秒 | 215 ミリ秒 |
| 1 秒あたりのページ ビュー数: | 56 | 94 |
| 平均 CPU (アプリケーション サーバーとフロントエンド Web サーバー) | 54 | 97 |
| 平均 CPU (SQL Server) | 7 | 9 |
| ピーク時のメモリ使用量 (アプリケーション サーバーとフロントエンド Web サーバー) | 8 GB | 8 GB |
次のグラフに、同じサイトでナビゲーションの種類を変えた場合の結果を示します。
図 10: 管理ナビゲーションと構造化ナビゲーション
コンピューターを追加することの効果 (スケール アウト)
SharePoint 展開からより多くのスループットが必要な場合は、スケールアウト (SharePoint Server 2013 をホストするコンピューターの数を増やす) を検討するオプションがあります。 次のグラフに、ファームにコンピューターを追加した場合のスループット増加の様子を示します。
図 11: フロントエンド Web サーバーを追加した場合のスループットに対する効果
テストでは、追加されたコンピューターごとに SharePoint Server 2013 を実行しているサーバーの負荷を増やし、サーバーの応答時間がほぼ同じになるようにしました (緑のゾーンの場合は約 11 ミリ秒、赤ゾーンでは約 250 ミリ秒)。
認証されたユーザーに対する作成者一括発行
SharePoint の発行機能は、サイトにアクセスするユーザーが認証されているイントラネットでも一般に使用されています。 このセクションでは、認証されたユーザーを使用して実施したテストと、その効果について説明します。
次の表に、認証されたユーザーが NTLM のクレーム ベース認証を使用してアクセスした場合の、作成者一括公開サイトのテスト結果を示します。 なお、このテストでも、前のセクションのテストと同じハードウェアを使用しました。
| テスト項目 | グリーン ゾーン | レッド ゾーン |
|---|---|---|
| VSTS ユーザー数: | 5 | 15 |
| Server Response Time 50th percentile: | 76 ミリ秒 | 107 ミリ秒 |
| Server Response Time 95th percentile: | 103 ミリ秒 | 194 ミリ秒 |
| 1 秒あたりのページ ビュー数: | 54 | 100 |
| 平均 CPU (アプリケーション サーバーとフロントエンド Web サーバー) | 50 | 97 |
| 平均 CPU (SQL Server) | 6 | 9 |
| ピーク時のメモリ使用量 (アプリケーション サーバーとフロントエンド Web サーバー) | 9.5 GB | 9.5 GB |
この数字は、サーバーの応答時間とスループットに関して、匿名要求と認証要求の間に大きな差がないことを示しています。
次のグラフに、同じサイトで要求の種類を変えた場合の結果を示します。
図 12: 匿名の要求と認証された要求
認証されたシナリオでの出力キャッシュの効果
サーバーに対する認証要求の場合、コンテンツにアクセスしているアカウントがそのコンテンツを表示する許可を持っていることを確認するために、要求がコンテンツ データベースとの間で往復する必要があります。 そのため、認証されたサイトでの出力キャッシュのパフォーマンス特性は、匿名サイトの場合と異なります。
次の表に、出力キャッシュを有効にして 90% のキャッシュ ヒット率で 10 分間実行した場合の結果を示します。
| テスト項目 | グリーン ゾーン | レッド ゾーン |
|---|---|---|
| VSTS ユーザー数: | 6 | 18 |
| Server Response Time 50th percentile: | 17 ミリ秒 | 29 ミリ秒 |
| Server Response Time 95th percentile: | 87 ミリ秒 | 118 ミリ秒 |
| 1 秒あたりのページ ビュー数: | 114 | 236 |
| 平均 CPU (アプリケーション サーバーとフロントエンド Web サーバー) | 50 | 97 |
| 平均 CPU (SQL Server) | 7 | 10 |
| ピーク時のメモリ使用量 (アプリケーション サーバーとフロントエンド Web サーバー) | 9.9 GB | 10 GB |
次のグラフに、これらの結果の概要を示します。
図 13: 認証された要求に対する出力キャッシュの効果
関連項目
概念
SharePoint Server で Web コンテンツ管理を計画する
SharePoint Server で Web コンテンツ管理ソリューションを構成する