ソーシャル環境のパフォーマンスと容量の要件を見積もる (SharePoint Server 2013)
適用対象:
2016 2019 Subscription Edition SharePoint in Microsoft 365
企業イントラネットの個人用サイトおよびソーシャル コンピューティング ポータル ソリューションに関するパフォーマンスと容量計画を作成するため、この記事では次の領域に関する情報を説明します。
ラボ環境の仕様。ハードウェア、ファーム トポロジ、ファーム構成など
テスト負荷の生成に使用された テスト ファームのワークロードとデータセット
テスト結果と分析。これらは、特定の規模の負荷条件におけるスループット、待機時間、およびハードウェアの要件の傾向を実証および説明するものです。
次の概念を理解するためにこの記事の情報を使用してください。
通常の負荷およびピーク時の負荷の下でのシナリオの特徴
ファーム サーバーのスケール アウト時のパフォーマンス傾向の変化
計画したアーキテクチャの適切な開始点を推定する方法
ピーク時の負荷でもファームが許容できるレベルのパフォーマンスを維持するのに必要なリソースの計画で考慮すべき重要な要素
この環境の概要
SharePoint Server 2013 は、認証されたユーザーがアクセスする個人用サイトやソーシャル コンピューティング ポータルをイントラネット サイトに公開するために多くの企業で使用されています。 この記事では、SharePoint Server 2013 で個人用サイトやソーシャル コンピューティング ポータルを公開するために必要なコンピューターの数や種類を計画する際に役立つ容量およびパフォーマンスのデータを紹介します。
追加のガイダンスでは、SharePoint Server 2013 エンタープライズの個人用サイトおよびソーシャル コンピューティング ポータル ソリューションでサーバーをスケール アウトする方法について説明します。 容量計画によって、購入する必要があるハードウェアや、ソリューションを最適化するシステム構成を判断することができます。
SharePoint Server 2013 の個々のファームは固有であるため、ハードウェア、ユーザーの操作、インストールされている機能の構成など多くの要因に基づく、ファームごとに異なる要件があります。 そのため、このガイダンスは実際の環境のハードウェアに対する追加テストの参考資料として使用してください。 計画した設計とワークロードがこの記事で説明されている環境と似ている場合は、この記事を使用してお使いの環境の規模を変更する方法を導き出すことができます。
この記事のテスト結果は、ワークロード、データセット、アーキテクチャを使用して、高度に制御された条件下で運用環境をシミュレートするテスト ラボで生成されました。 これらのテストの設計には細心の注意が払われましたが、テスト ラボのパフォーマンス特性は運用環境の動作と同じではありません。 このテスト結果は運用ファームのパフォーマンスと容量の特性を表すものではありません。 それよりも、テスト結果は、スループット、待機時間、およびハードウェアの要件の観測傾向を示しています。 実際のファーム容量の計画および管理に役立つ観測データの分析を使用してください。
この記事の内容は次のとおりです。
仕様 (ハードウェア、トポロジ、および構成など)
ワークロード (ファーム、ユーザー数、使用の特性に関する要件の分析など)
データセット (データベースのサイズとコンテンツの種類など)
Web サーバーのスケールアウトのためのテスト結果と分析
この記事を読む前に、次の記事を参照して、SharePoint Server 2013 での容量管理の背後にある重要な概念を理解してください。
これらの記事では、次の情報を説明しています。
容量管理に対して推奨されるアプローチ
この記事の情報を効率的に利用する方法
用語集
次のリストに、この記事で使用する主な用語の定義を示します。
RPS: 1 秒あたりの要求数。 RPS はファームまたはサーバーが 1 秒あたりに受信した要求の数です。 これはサーバー負荷とファーム負荷の一般的な計測方法です。
重要
要求はページ ロードとは異なります。 各ページにはいくつかのコンポーネントが含まれ、ブラウザーがページを読み込むときに、各コンポーネントは 1 つ以上の要求を生成します。 したがって、1 回のページ ロードで複数の要求が作成されます。 通常、認証チェックと、重要ではないリソースを使用するイベントは、RPS 計測ではカウントされません。
グリーン ゾーン: グリーン ゾーンは、予想される日ごとのピーク負荷の範囲内の、通常の運用条件の下で動作している、一連の定義済み負荷特性を表します。 この範囲内で動作するファームは、応答時間と待機時間を許容できるパラメーター内に維持できていると考えることができます。
以下は、サーバーが次の一連の条件を維持できる状態です。
要求の少なくとも 75% でのサーバー側待機時間が 0.5 秒未満である。
すべてのサーバーで、平均 CPU 使用率が 50% 未満を維持している。
障害発生率が 0.1% 未満である。
レッド ゾーン (最大): レッド ゾーンは、ピーク時の運用条件の下での一連の定義済み負荷特性を表します。 レッド ゾーンでは、ファームのリソース要件の変動が激しく、障害や、他のパフォーマンスおよび信頼性の問題が発生するまでの限られた期間のみ維持できます。
これは、サーバーが限られた期間に次の一連の条件を維持できる状態です。
要求の少なくとも 75% でのサーバー側待機時間が 1 秒未満である。
データベース サーバーの平均 CPU 使用率が 80% 未満である。
障害発生率が 0.1% 未満である。
概要
ここでは、スケーリング方法、このラボ環境と類似するケース スタディ環境の関係、およびテスト方法について説明します。
スケーリング方法
環境内のコンピューターは、テスト ラボ環境のスケーリングに使用されたのと同じ順序でスケーリングすることをお勧めします。 この方法を採用することにより、ワークロードの最適な構成を見つけることができます。
パフォーマンス テスト サイクルは 3 つの負荷カテゴリに分かれています。 カテゴリの境界を決定する基本パラメーターはユーザー プロファイル数で、テストの境界は 10K、100K、および 500K ユーザー プロファイルに設定されています。 別のパラメーターは、一連のソーシャル機能に関連するアクションを実行しているアクティブ ユーザー数です。 プロファイルを持つユーザー数とアクティブ ユーザー数の双方を考慮に入れて、実際の展開に似た条件でアプリケーションの使用状況をシミュレートするテストを実行しました。 次の表に、初期データ セットとアクティブなユーザー数を示します。
初期データセット
| Entity | 機能を使用するユーザーの割合 (%) | 小規模 (10K ユーザー) | 中規模 (100K ユーザー) | 大規模 (500K ユーザー) |
|---|---|---|---|---|
| ユーザーのユーザー プロファイル数 |
100% |
10K |
100K |
500K |
| プロビジョニングされた個人用サイト数 |
100% |
10K |
100K |
500K |
| ユーザー写真があるユーザー プロファイル数 |
50% |
5K |
50K |
250K |
| 投稿があるユーザー プロファイル数 |
10% |
1K |
10K |
50K |
| チーム数 |
1,860 |
18,600 |
93K |
|
| 1 日あたりのアクティブ ユーザー数 |
10% |
1K |
10K |
50K |
| 1 時間あたりのアクティブ ユーザー数 |
5% |
500 |
5K |
25K |
テストは、次の重要なシナリオに重点を置いて実行しました。
ニュース フィード ページへのアクセスとその他のアクション
プロファイル ページ
サイト フィード ページへのアクセスとその他のアクション
Outlook Social Connector のアクティビティ フィードの同期
OneDrive ページ アクセス
OneDrive クライアントの使用状況
現実的な展開シナリオをシミュレートするため、すべてのテストはデータが既に含まれているデータベース上で実行しました。 データセットには、平均して 1 チームあたり 4 ～ 6 ユーザー、3 ～ 4 レベルの深さを持つ組織ツリーのモデルを使用しました。 これらの数値は、内部ソーシャル サイトからのトラフィックを分析して算出しました。 初期データ セットを構築するために使用したパラメーターのセットを次の表に示します。
初期データベースのデータ モデル
| データ エンティティの説明 | 番号 |
|---|---|
| 1 チーム内の平均ユーザー数 |
5 |
| 組織ごとの平均レベル数 |
4 |
| 1,000 ユーザーごとのチーム数 |
186 |
| ユーザー 1 人がフォローする仕事仲間の平均数 |
50 |
| ユーザー プロファイル プロパティ数 |
93 |
データが作成されるアクションに関するパラメーターのセットを次の表に示します。
利用状況特性
| パラメーター | 数または割合 (%) |
|---|---|
| 1 ～ 3 件の投稿があるユーザーの割合 |
10% |
| ユーザーあたりの平均投稿数 |
2 |
| 投稿あたりの平均返信数 |
2 |
| "いいね" される投稿の割合 |
15% |
| リンクを含む投稿の割合 |
5% |
| タグを含む投稿の割合 |
12% |
| ユーザーからのメンションがある投稿の割合 |
8% |
| 添付画像を含む投稿の割合 |
5% |
各スケール テストを作成するにあたり、前述のデータ セットとアクティブ ユーザー数に加えて、次のアクションを適用しました。
ユーザーの読み取り操作
| ユーザー操作 | 操作を実行するユーザーの割合 (%) | シナリオ | 機能または URL |
|---|---|---|---|
| 個人用サイト ホーム ページに移動する |
12% |
ニュースフィード |
ニュースフィード ページ (http://my/default.aspx) |
| ユーザーのパブリック プロファイル ページに移動する |
8% |
プロファイル |
[プロファイル] ページ (http://my/person.aspx?accountname=<alias>) |
| ユーザーのプライベート プロファイル ページに移動する |
4% |
プロファイル |
プロファイル ページ (http://my/person.aspx) |
| アクティビティ フィードを自動同期する |
32% |
Outlook Social Connector |
なし |
|
フォロー中ページに移動する |
3% |
フォロー相手リスト |
http://my/MyPeople.aspx |
| 既定のドキュメント ライブラリに移動する |
6% |
OneDrive |
https://msft-my.spoppe.com/personal/<user>/Documents |
| フォローされたドキュメント ページに移動する |
3% |
OneDrive |
https://msft-my.spoppe.com/personal/<user>/Social/FollowedContent.aspx |
| フォローされたドキュメント ページに移動する |
3% |
OneDrive |
https://msft-my.spoppe.com/personal/<user>/Social/FollowedContent.aspx |
| サイト フィード ページに移動する |
8% |
サイトのフィード |
サイト フィード ページ (https://<domain>/teams/<site>/newsfeed.aspx_ |
| スレッド上のすべての返信を表示する |
1% |
ニュースフィード |
ニュースフィード ページ (http://my/default.aspx) |
|
全員フィードを表示する |
3% |
ニュースフィード |
ニュースフィード ページ (http://my/default.aspx) |
| 他の投稿をニュースフィードに表示する |
2% |
ニュースフィード |
ニュースフィード ページ (http://my/default.aspx) |
|
@mentions ページを表示する |
1% |
ニュースフィード |
ニュースフィード ページ (http://my/default.aspx) |
| ニュースフィードの表示 (モバイル) |
1% |
携帯電話 |
モバイル REST (Representational State Transfer) 呼び出し |
| ニュースフィードの分類表示 |
3% |
携帯電話 |
モバイル REST 呼び出し |
ユーザーの書き込み操作
| ユーザー操作 | パーセンテージ | シナリオ | 機能または URL |
|---|---|---|---|
| フィードに最初の投稿を作成する |
0.5% |
ニュースフィード |
ニュースフィード ページ (http://my/default.aspx) |
| フィード内の投稿に "いいね" する |
0.3% |
ニュースフィード |
ニュースフィード ページ (http://my/default.aspx) |
| フィード内の投稿に返信する |
0.7% |
ニュースフィード |
ニュースフィード ページ (http://my/default.aspx) |
| を使用してフィードに投稿を作成する @mention |
0.1% |
ニュースフィード |
ニュースフィード ページ (http://my/default.aspx) |
| サイト フィードに最初の投稿を作成する |
0.5% |
サイトのフィード |
サイト フィード ページ (https://<domain>/teams/<site>/newsfeed.aspx) |
| を使用してサイト フィードに投稿を作成する @mention |
0.5% |
サイトのフィード |
サイト フィード ページ (https://<domain>/teams/<site>/newsfeed.aspx) |
| サイト フィード内の投稿に返信する |
0.15% |
サイトのフィード |
サイト フィード ページ (https://<domain>/teams/<site>/newsfeed.aspx) |
| タグ付きでサイト フィードに投稿を作成する |
0.05% |
サイトのフィード |
サイト フィード ページ (https://<domain>/teams/<site>/newsfeed.aspx) |
OneDrive クライアント アクション
| ユーザー アクション** | パーセンテージ | シナリオ | 機能または URL |
|---|---|---|---|
| OneDrive の初期同期 |
0.2% |
OneDrive |
初期同期 |
| OneDrive 増分同期 - ファイルをダウンロードする |
0.88% |
OneDrive |
増分同期 |
| OneDrive 増分同期 - 変更なし |
8.1% |
OneDrive |
増分同期 |
テスト手法
このテストは、ソーシャル機能の最小限の SharePoint Server 2013 ファーム構成から開始しました。 ソーシャル機能の負荷特性をテスト ファームに適用し、負荷を増加させながらサーバーの処理能力が通常レベルおよび最大レベルに達する点を観察しました。 それぞれの負荷レベルでボトルネックを分析し、過負荷状態のロール用のコンピューターを追加して、ファーム構成をスケール アウトしました。 この追加により、各ケースでボトルネックが緩和され、特定のデータセットに関するサーバーのスケーラビリティ特性を確認することができました。 典型的な SharePoint Server 2013 ファームのスケーラビリティ特性の概要と容量計画のためのガイドラインを提供するために、このスケール アウト プロセスを 3 つの展開サイズについて繰り返しました。
仕様
このセクションでは、ラボ環境のハードウェア、ソフトウェア、トポロジ、および構成の詳細について説明します。
重要
テスト ラボの Web サーバーとアプリケーション サーバーはすべて、Hyper-V ホストを使用して仮想化されています。 データベース サーバーは仮想化されていません。 物理ホスト ハードウェアと仮想マシンの仮想ハードウェアについては、それぞれ次のセクションで詳細を示します。
ハードウェア
次の表は、このテストで使用されたコンピューターのハードウェア仕様を示しています。 テストの複数の反復中にサーバー ファームに追加されたフロントエンド Web サーバーもこれらの仕様と一緒にまとめられています。
Hyper-V ホスト
ファームには同一構成の Hyper-V ホストが全部で 3 台含まれており、各ホストは 1 ～ 4 台の仮想マシンを実行します。
| ホスト ハードウェア | 値 |
|---|---|
|
プロセッサ |
2 クアッドコア 2.27 GHz プロセッサ |
|
RAM |
64 GB |
|
オペレーティング システム |
Windows Server 2008 R2 SP1 |
|
ネットワーク アダプター数 |
2 |
|
ネットワーク アダプターの速度 |
1 ギガビット |
仮想 Web サーバーとアプリケーション サーバー
ファームには 1 ～ 8 台の仮想 Web サーバーがあります。 追加の 1 台の専用仮想サーバーが Distributed Cache Service を実行しています。
注:
通常、運用環境では、Distributed Cache Service を実行する専用サーバーは高可用構成で展開されます。 このテストの目的では高可用性は重要な要因ではないため、Distributed Cache 専用として 1 台のサーバーを使用しました。
| VM ハードウェア | Web サーバー |
|---|---|
|
プロセッサ |
4 つの仮想プロセッサ |
|
RAM |
12 GB |
|
オペレーティング システム |
Windows Server 2008 R2 SP1 |
|
SharePoint ドライブのサイズ |
100 GB |
|
ネットワーク アダプター数 |
2 |
|
ネットワーク アダプターの速度 |
1 ギガビット |
|
認証 |
Windows NTLM |
|
ロード バランサーの種類 |
F5 Big IP |
|
ローカルで実行されているサービス |
Microsoft SharePoint Foundation Web アプリケーション、Microsoft SharePoint Foundation 受信メール、Microsoft SharePoint Foundation ワークフロー タイマー サービス、管理されたメタデータ Web サービス、ユーザー プロファイル サービス |
| VM ハードウェア | キャッシュ |
|---|---|
|
プロセッサ |
4 つの仮想プロセッサ |
|
RAM |
12 GB |
|
オペレーティング システム |
Windows Server 2008 R2 SP1 |
|
SharePoint ドライブのサイズ |
100 GB |
|
ネットワーク アダプター数 |
2 |
|
ネットワーク アダプターの速度 |
1 ギガビット |
|
認証 |
Windows NTLM |
|
ローカルで実行されているサービス |
Distributed Cache、Microsoft SharePoint Foundation ワークフロー タイマー サービス |
| VM ハードウェア | 検索クエリ コンポーネント |
|---|---|
|
プロセッサ |
4 つの仮想プロセッサ |
|
RAM |
12 GB |
|
オペレーティング システム |
Windows Server 2008 R2 SP1 |
|
ネットワーク アダプター数 |
2 |
|
ネットワーク アダプターの速度 |
1 ギガビット |
|
認証 |
Windows NTLM |
|
ローカルで実行されているサービス |
Microsoft SharePoint Foundation Web アプリケーション、Microsoft SharePoint Foundation 受信メール、Microsoft SharePoint Foundation ワークフロー タイマー サービス、検索クエリおよびサイト設定サービス、SharePoint Server Search |
| VM ハードウェア | 検索インデックス コンポーネント |
|---|---|
|
プロセッサ |
4 つの仮想プロセッサ |
|
RAM |
12 GB |
|
オペレーティング システム |
Windows Server 2008 R2 SP1 |
|
ネットワーク アダプター数 |
2 |
|
ネットワーク アダプターの速度 |
1 ギガビット |
|
認証 |
Windows NTLM |
|
ローカルで実行されているサービス |
Microsoft SharePoint Foundation Web アプリケーション、Microsoft SharePoint Foundation 受信メール、Microsoft SharePoint Foundation ワークフロー タイマー サービス、SharePoint Server Search |
データベース サーバー
1 台の物理データベース サーバーが、SharePoint データベースを含む既定の SQL Server インスタンスを実行します。 この記事では、ログ データベースは追跡しません。
注:
使用状況レポートを有効にする場合、別の論理ユニット番号 (LUN) にログ データベースを格納することをお勧めします。 大規模な展開および一部の中規模な展開では、ボリュームの大きいログ イベントが発生するプロセッサでの要求に応えるため、専用のログ データベース サーバーが必要となる場合があります。 > このラボ環境では、ログ記録が制約され、ログ データベースが SQL Server の別のインスタンスに格納されました。
データベース サーバー - 既定のインスタンス
|
プロセッサ |
2 クアッドコア 3.3 GHz プロセッサ |
|
RAM |
32 GB |
|
オペレーティング システム |
Windows Server 2008 R2 SP1 |
|
ストレージとジオメトリ |
直接接続ストレージ (DAS) 300 GB 15krpm ディスクを 6 台使用した内部アレイ 450 GB 15krpm ディスクを 15 台使用した内部アレイ 50 x コンテンツ データ (外部 RAID10、2 x 3 スピンドル、各 300 GB) 50 x コンテンツ ログ (内部 RAID10、2 x 2 スピンドル、各 300 GB) 1 x 一時データ (内部 RAID10、2 x 2 スピンドル、各 300 GB) 1 x 一時ログ (内部 RAID10、2 x 2 スピンドル、各 300 GB) |
|
ネットワーク アダプター数 |
1 |
|
ネットワーク アダプターの速度 |
1 ギガビット |
|
認証 |
Windows NTLM |
|
ソフトウェアのバージョン |
SQL Server 2008 R2 |
トポロジ
次の表は、このラボ環境のトポロジを示しています。
ラボ環境のトポロジ
| 役割 | 小規模展開 (10k ユーザー) | 中規模展開 (100k ユーザー) | 大規模展開 (500k ユーザー) |
|---|---|---|---|
| Web サーバー |
2-4 |
4-8 |
8 |
| キャッシュ |
1 |
1 ～ 2 |
3 |
| SQL Server |
1 |
1 ～ 2 |
2 |
テスト プロセス
重要
テストでシミュレートしているのは、通常の営業時間内の典型的なソーシャル コンピューティング ポータルの使用量だけです。 昼/夜の周期により生じるユーザーが生成するトラフィックの周期的な変化は考慮していません。 プロファイルの同期、ひとの検索クロールなど、相当な量のリソースを必要とするタイマー ジョブは、その影響を特定するために同じテスト ワークロードを使用して個別にテストしました。 > テストでは、ニュースフィード、ソーシャル タグ付け、ユーザー プロファイルの読み取りなどのソーシャル操作に重点を置きます。 テスト ミックスに含まれる典型的なコラボレーション トラフィックは少量であるため、運用環境をより的確にシミュレートすることができます。 これらの結果を、個人用サイトとソーシャル機能専用の個別のポータルの設計にぜひご活用ください。 > テスト ミックスには、検索コンテンツ クロールからのトラフィックは含まれません。 >
小、中、大規模な展開に対して、ソーシャル機能のテストを実施しました。 サーバー ハードウェアの構成にあたっては、最小サイズの最小限の構成から開始し、「スケーリング方法」セクションで説明されているとおりに、テスト データベースにデータセットのデータを格納しました。
サーバーに対して最初は小さな負荷をかけ、作業負荷をシミュレートしながらソーシャル機能の負荷特性を適用するのに、Visual Studio Team System (VSTS) を使用しました。 ゆっくり均一に負荷を増加し、すべてのサーバー ロールのパフォーマンス ・ メトリックを記録して、最大 RPS を確認しました。 最大 RPS は、ファームへの負荷を増加させても、サーバーのボトルネック制約が原因で、達成される RPS 出力に増加が見られない状態として認識できます。
これらの記録されたメトリックから、緑のゾーンと赤いゾーンの状態を定義しました。これは、特定のコンピューター構成での VM サーバーの通常の状態と完全に読み込まれた状態を表します。 次に、グリーン ゾーン レベルとレッド ゾーン レベルの両方で安定した負荷を適用し、これらの負荷での定常状態のパフォーマンス メトリックを分析しました。 これにより、トポロジ構成ごとに、これらの主要な読み込み条件の下で VM サーバーのサーバーの正常性とパフォーマンスの表現が提供されました。
グリーン ゾーンとレッド ゾーンそれぞれの負荷特性、および各トポロジのスケール曲線を理解してから、RPS を制限するスケーリングのボトルネックを特定しました。 ソーシャル ワークロードの場合、通常、ボトルネックは小規模データセット用の Web サーバー CPU でした。 大規模なデータセットでは、Distributed Cache ノードのメモリ負荷も観察されました。 各ケースのボトルネックを解消するため、過負荷状態のロール用の仮想サーバーを構成に追加し、スケール アウト処理を続行しました。 次に、構成サイズごとのパフォーマンス傾向の分析と、グリーンおよびレッド ゾーンそれぞれの定義とそれらの傾向との一致に関する分析を、特定の展開サイズの要件に達するまで繰り返しました。
それぞれの展開サイズを理解した後、テスト ファームをもう 1 段階大きいサイズの最小構成に再構成し、「スケーリング方法」セクションで説明されているとおりにデータセットを作成して、分析とスケール アウト処理を繰り返しながら、各データ セット サイズのスケール アウト特性を測定しました。
結果と分析
このセクションでは、3 つの展開サイズの測定結果を示します。 具体的には、Web サーバーを追加してサーバー ファームをスケール アウトすることで、グリーン ゾーンとレッド ゾーンの RPS、待機時間、および平均 CPU 使用率にどのような影響が及ぶかが示されています。
次の傾向は 3 つの展開サイズすべてに共通の傾向でした。
グリーン ゾーンとレッド ゾーンの RPS は、仮想 Web サーバーの数に応じて直線的に増加します。
テストされた構成全体での主要なボトルネックは、Web サーバーの CPU でした。
レッド ゾーンでは、Web サーバーを追加して負荷を増やすと、わずかに待機時間が長くなります。 これは、SQL Server および Distributed Cache Service (テスト ファーム内のすべての Web サーバーで実行している) への負荷が増すことによるものです。
さらに、SQL Server および Distributed Cache コンピューターの平均 CPU 使用量は、Web サーバーが増えるにつれて増加します。 これは、SQL Server および Distributed Cache Service 上のキャッシュ負荷が増すことによるものです。
グリーン ゾーンの待機時間は、Web サーバーの数が増えてもほぼ一定です。 これは、グリーン ゾーンの負荷レベルでは Web サーバーが過負荷にまではならないためです。
小規模でのテスト結果
グリーン ゾーンとレッド ゾーンの双方に関して、Web サーバー数の増加が RPS に及ぼす影響を次のグラフに示します。
グリーン ゾーンとレッド ゾーンの双方に関して、Web サーバー数の増加が待機時間に及ぼす影響を次のグラフに示します。
グリーン ゾーンとレッド ゾーンの双方に関して、Web サーバー数の増加が平均 CPU 使用率に及ぼす影響を次のグラフに示します。
中規模でのテスト結果
グリーン ゾーンとレッド ゾーンの双方に関して、Web サーバー数の増加が RPS に及ぼす影響を次のグラフに示します。
グリーン ゾーンとレッド ゾーンの双方に関して、Web サーバー数の増加が待機時間に及ぼす影響を次のグラフに示します。
グリーン ゾーンとレッド ゾーンの双方に関して、Web サーバー数の増加が平均 CPU 使用率に及ぼす影響を次のグラフに示します。
大規模でのテスト結果
グリーン ゾーンとレッド ゾーンの双方に関して、Web サーバー数の増加が RPS に及ぼす影響を次のグラフに示します。
グリーン ゾーンとレッド ゾーンの双方に関して、Web サーバー数の増加が待機時間に及ぼす影響を次のグラフに示します。
グリーン ゾーンとレッド ゾーンの双方に関して、Web サーバー数の増加が平均 CPU 使用率に及ぼす影響を次のグラフに示します。
Web サーバーの数が増えると、次のイベントが発生します。
SQL Server および Distributed Cache ノードの平均 CPU 使用率が高くなります。これは、共有リソースに対する負荷が増すことによるものです。
レッド ゾーンでは、Web サーバーの平均 CPU 使用率がわずかに低くなります。これは、ボトルネックが SQL Server および Distributed Cache コンピューターにわずかに移ることによるものです。
グリーン ゾーンでは、Web サーバーの平均 CPU 使用率は一定です。これは、サーバーの負荷が推奨レベルに留まることによるものです。
推奨事項
パフォーマンスの観点から SharePoint Server 2013 のソーシャル展開の成否を測定する場合、成否は次の要素に依存します。
サポートするアクティブ ユーザー数
予想される読み取りおよび書き込み操作のトランザクション ミックス
ファーム サーバー間で負荷を分散する方法
予想されるアクティブ ユーザー数は、トポロジ内に含めることを計画する必要があるサーバー数を決定する主要因の 1 つです。 アクティブなユーザー数は、サーバー間のソーシャル シナリオのために有効にする必要があるさまざまなサービスのホスティング構成をも決定します。
このテストでは一般的なデータセットを使用して、実際の展開で考えられる複雑な負荷を適用しましたが、それぞれの展開は独特のものです。 容量計画では、予想される使用率の特性、機能構成、およびハードウェア リソースの可用性について検討してください。 容量の数値に重要な影響を及ぼし、これを変更する可能性がある要因としては、次のものがあります。
メールの使用パターンによっては、Outlook Social Connector によって生成される負荷が増加する場合があります。
書き込みアクションの割合が大幅に増加します (たとえば、トランザクション ミックスでのタグ付けや @mention) の増加により、データベース サーバーの負荷が増加する可能性があります。
Web サーバーを追加または削除して、Web サーバーや SQL Server、Distributed Cache ノード間で CPU 負荷のバランスを取ることができます。
最適なパフォーマンスを得るには、SharePoint Server 2013 の標準構成ガイドに注意深く従ってください。 ソーシャル トランザクションで特に重要な考慮事項は次のとおりです。
プロファイル DB 用の独立した物理ディスク - ソーシャル トランザクションでは、プロファイル DB を頻繁に使用するため、プロファイル DB は SQL Server が実行されているサーバー上の専用物理ディスク セットに保持することをお勧めします。
User Profile Service アプリケーションのメモリ要件 - User Profile Service アプリケーションはフロント エンド Web サーバー上に配置され、メモリ内キャッシュに大きく依存しています。 フロント エンド Web サーバーに、多数のデータ要求をキャッシュするのに十分な RAM があるかどうかを確認します。 推奨されている最小 RAM は、フロント エンド Web サーバーごとに 12 GB です。
Distributed Cache サーバーのメモリ要件 - ソーシャル機能 (特に microblogging) は、容量が十分で堅牢な Distributed Cache ストレージに大きく依存しています。 これらのコンピューターのメモリが不足すると、キャッシュの再作成時に SharePoint ファームの能力が低下する原因となる場合があります。 したがって、Distributed Cache をホストするサーバーについては、少なくとも 12 GB の RAM を使用する構成とし、展開内の総ユーザー数に基づき、必要に応じてスケール アウトすることをお勧めします。
SharePoint Server 2013 のソーシャル展開では、ソーシャル機能を使用するすべてのユーザーが個人用サイトを準備する必要があります。 コンテンツ データベース レベルでの個人用サイト コレクションの作成の拡張を計画します。 個人用サイト コレクションのスケール方法の詳細については、「ソフトウェアの境界と制限 (SharePoint 2013)」を参照してください。
関連項目
概念
SharePoint Server 2013 のパフォーマンス計画