部門ポータル環境のラボ研究 (SharePoint Server 2010)
適用先: SharePoint Server 2010
トピックの最終更新日: 2016-11-30
このドキュメントでは、Microsoft SharePoint Server 2010 を基盤とする部門ポータルのパフォーマンスと容量の計画に関するガイダンスを示します。主な内容は以下のとおりです。
テスト環境の仕様 (ハードウェア、ファーム トポロジ、構成など)
テスト ファームのデータセット
テスト データと推奨事項。推奨事項には、似た環境を展開するために必要なハードウェア、トポロジ、および構成をどのように決定するかに関する推奨事項と、適切な容量とパフォーマンスの特性に合わせて環境をどのように最適化するかに関する推奨事項が含まれます
この記事の内容:
この環境の概要
用語集
概要
仕様
結果と分析
この環境の概要
このドキュメントでは、テストの方法と結果について説明し、標準的な部門ポータルの容量計画に関するガイダンスを示します。部門ポータルは、SharePoint Server 2010 展開であり、チームで主にグループ作業といくつかのコンテンツ発行作業を行う場所です。このドキュメントでは、"部門" を、1,000 ～ 10,000 人の従業員がいる企業内の 1 つの組織と仮定します。
シナリオごとに要件は異なります。つまり、ユーザー独自のハードウェアと環境で追加のテストを実行することでこのガイダンスを補完することが重要です。計画している設計とワークロードがこのドキュメントで説明されている環境と似ている場合、このドキュメントを使用して、環境のスケール アップとスケール アウトに関する結論を引き出すことができます。
このドキュメントを読むことで次の方法を理解できます。
ユーザー数、ロード、有効にする機能など、サポートする必要のある規模をサポートするのに必要なハードウェアを評価する。
最適な信頼性と効率を得るための物理トポロジと論理トポロジを設計する。高可用性/障害復旧はこのドキュメントに含まれません。
進行中の検索クロールが部門ポータル展開の RPS に与える影響を理解する。
このドキュメントで説明する SharePoint Server 2010 環境は、大規模企業での運用環境を模倣するラボ環境です。運用環境の詳細については、「部門の共同作業環境の技術的ケース スタディ (SharePoint Server 2010)」を参照してください。
このドキュメントを読む前に、SharePoint Server 2010 での容量管理の基本的な考え方を必ず理解しておいてください。このドキュメントは、容量管理を行うための推奨アプローチを学習するうえで役立ちます。ここでは、このドキュメントの情報を効果的に利用する方法を理解する際に役に立つ背景情報を提供するほか、このドキュメントで使用されている用語を定義します。
また、次のドキュメントを読むことをお勧めします。
用語集
このドキュメントでは、専門的な用語がいくつか使用されています。以下は、重要な用語とその定義です。
RPS: 1 秒あたりの要求数。1 秒間にファームまたはサーバーが受信した要求の数。これはサーバー ロードおよびファーム ロードの一般的な計測基準です。
要求は、ページ ロードとは異なる点に注意してください。各ページには複数のコンポーネントが含まれ、それらは、ページが読み込まれるときに 1 つまたは複数の要求を作成するからです。したがって、1 つのページ ロードで複数の要求が作成されます。一般的には、認証チェックと、重要ではないリソースを使用するイベントは、RPS 計測ではカウントされません。
グリーン ゾーン: これは、サーバーが以下の一連の要件を維持することができる状態です。
要求の 75 % 以上で、サーバー側の待機時間が 0.5 秒未満。
すべてのサーバーの CPU 使用率が 50% 未満。
注意
このラボ環境ではアクティブな検索クロールが実行されていなかったので、データベース サーバーの CPU 使用率は 40% 以下に維持され、検索クロール ロードは 10% に維持されていました。ここでは、検索クロール ロードを 10% CPU に制限するために、運用環境で Microsoft SQL Server リソース ガバナーが使用されているものとします。
- 障害発生率が 0.01% 未満。
レッド ゾーン (最大): これは、サーバーが以下の一連の要件を維持することができる状態です。
HTTP 要求調整機能が有効であるが、503 エラー (サーバー使用中) が返されない。
障害発生率が 0.1% 未満。
要求の 75 % 以上で、サーバー側の待機時間が 1 秒未満。
SQL Server リソース ガバナーを使用して、データベース サーバーの CPU 使用率が 75% 以下に制限され、検索クロール ロード用に 10% が確保されている。
すべての Web サーバーの CPU 使用率が 75% 以下。
AxBxC (グラフの注釈): これは、それぞれファーム内の Web サーバー数、アプリケーション サーバー数、データベース サーバー数を表します。たとえば、2x1x1 は、この環境に 2 台の Web サーバー、1 台のアプリケーション サーバー、1 台のデータベース サーバーが含まれることを意味します。
**MDF と LDF:**SQL Server 物理ファイル。詳細については、「ファイルとファイル グループのアーキテクチャ」を参照してください。
概要
このセクションでは、前提条件およびテスト方法の概要について説明します。
前提事項
テストの前提条件は以下のとおりです。
このテストの範囲では、ディスク I/O が制限要因として考慮されませんでした。無限のスピンドル数を利用できるという前提です。
テストでは、標準的な部門ポータルにおけるピーク時の使用状況のみがモデル化されました。昼夜の周期で見られるトラフィックの周期的な変化は考慮されませんでした。また、これは、深夜の定期的な実行が一般的に必要とされるタイマー ジョブがミックスに含まれないことも意味します。
この場合、部門ポータル展開で実行されるカスタム コードはありません。ユーザーの部門ポータルにインストールされて実行されるカスタム コード/サードパーティ ソリューションの動作を保証できません。
これらのテストを行う目的で、すべてのサービス データベースとコンテンツ データベースは Microsoft SQL Server の同じインスタンスに配置されました。利用状況データベースは、SQL Server の独立したインスタンスで管理されました。
これらのテストを行う目的で、BLOB キャッシュが有効にされています。
検索クロールのトラフィックはこれらのテストで考慮されていません。ただし、進行中の検索クロールの影響を考慮に入れるため、正常なファームの定義を変更しました (検索クロールからの 10% 負担が確保されるように、グリーン ゾーンの定義を変更して SQL Server を 40% としました。同様に、80% の SQL Server CPU 使用率を最大 RPS の条件として使用しました)。
テスト方法
Visual Studio Team System for Test 2008 SP2 を使用してパフォーマンス テストを実施しました。テストの目標は、トポロジごとに、グリーン ゾーン、最大ゾーン、およびその中間にあるさまざまなシステム ステージにおけるパフォーマンス特性を確認することでした。"最大ゾーン" と "グリーン ゾーン" の詳細な定義は、「用語集」で説明されています。これらは、パフォーマンス カウンターの特定の値で測定されます。ただし、一般的に、"最大ゾーン" ブレークポイントの前後で実行されるファーム構成はストレスを受けるとみなすことができるのに対して、"グリーン ゾーン" ブレークポイントで実行されるファーム構成は正常であるとみなすことができます。
テストは、最も基本的なファーム構成を使用することから開始し、一連のテストを実行する方法で行われました。最初のテストは、システムのロードを徐々に増加し、そのパフォーマンス特性を監視することでした。このテストから、さまざまなユーザー ロードにおけるスループットと待機時間を求め、システムのボトルネックを特定しました。また、このデータを取得した後、どの程度のユーザー ロードでファームがグリーン ゾーンおよび最大ゾーンの特性を示したかを特定しました。事前に特定したこれらの一定のユーザー ロードで、独立したテストを長期間実行しました。これらのテストによって、ファーム構成が、グリーン ゾーンと最大ゾーンの一定のパフォーマンスをそれぞれのユーザー ロードで長期間にわたって提供できることが確認されました。
その後、次の構成のテストを実行しながら、システムをスケール アウトし、以前の実行で特定されたボトルネックを排除しました。SQL Server CPU のボトルネックに達するまで、この方法を反復しました。
最初は、1 台の Web サーバー/アプリケーション サーバーと 1 台のデータベース サーバーの最小ファーム構成から開始しました。反復を複数回繰り返すことで、最終的に 3 台の Web サーバー、1 台のアプリケーション サーバー、1 台のデータベース サーバーのファーム構成で終了しました。ここで、データベース サーバーの CPU は最高限度に達しました。構成のグリーン ゾーンと最大ゾーンを確立するために各反復で実行したテストの概要とグラフを以降に示します。その次に、各反復でのグリーン ゾーンと最大ゾーンを比較し、そこから推奨事項を導きます。
SharePoint Admin Toolkit チームは、"Load Test Toolkit (LTK)" と呼ばれるツールを構築し、顧客に公開しました。顧客はこのツールをダウンロードして使用できます。
仕様
このセクションでは、ラボ環境のハードウェア、ソフトウェア、トポロジ、および構成の詳細について説明します。
ハードウェア
以下の表に、このテストで使用されたコンピューターのハードウェア仕様を示します。テストの複数回の反復中にサーバー ファームに追加されたすべての Web サーバーは、同じ仕様に準拠します。
| Web サーバー | アプリケーション サーバー | データベース サーバー | |
|---|---|---|---|
プロセッサ |
2 プロセッサ x 4 コア 2.33 GHz |
2 プロセッサ x 4 コア 2.33 GHz |
4 プロセッサ x 4 コア 3.19GHz |
RAM |
8 GB |
8 GB |
32 GB |
ネットワーク アダプターの数 |
2 |
2 |
1 |
ネットワーク アダプターの速度 |
1 ギガビット |
1 ギガビット |
1 ギガビット |
ロード バランサーの種類 |
F5 - ハードウェア ロード バランサー |
該当なし |
該当なし |
ULS ログ レベル |
中 |
中 |
該当なし |
ソフトウェア
以下の表に、このテスト作業で使用されたサーバーにインストールされて実行されたソフトウェアを示します。
| Web サーバー | アプリケーション サーバー | データベース サーバー | |
|---|---|---|---|
オペレーティング システム |
Windows Server 2008 R2 x64 |
Windows Server 2008 R2 x64 |
Windows Server 2008 x64 |
ソフトウェアのバージョン |
SharePoint Server 2010 および Office Web アプリケーションのプレリリース版 |
SharePoint Server 2010 および Office Web アプリケーションのプレリリース版 |
SQL Server 2008 R2 CTP3 |
認証 |
Windows NTLM |
Windows NTLM |
Windows NTLM |
ロード バランサーの種類 |
F5 - ハードウェア ロード バランサー |
該当なし |
該当なし |
ULS ログ レベル |
中 |
中 |
該当なし |
ウイルス対策の設定 |
無効 |
無効 |
無効 |
ローカルで実行されているサービス |
Microsoft SharePoint Foundation 受信電子メール Microsoft SharePoint Foundation Web アプリケーション Microsoft SharePoint Foundation Workflow Timer Service Search Query and Site Settings Service SharePoint Server Search |
サーバーの全体管理 Excel Services Managed Metadata Web Service Microsoft SharePoint Foundation 受信電子メール Microsoft SharePoint Foundation Web アプリケーション Microsoft SharePoint Foundation Workflow Timer Service PowerPoint Service Search Query and Site Settings Service SharePoint Server Search Visio Graphics Services Word Viewing Service |
該当なし |
この表は、テスト環境で準備されたサービスを示しています。User Profile Service、Web Analytics のような、その他のサービスは準備されていません。
トポロジと構成
次の図は、テストで使用されたトポロジを示しています。反復を繰り返すうちに、Web サーバーの台数が 1 台から 2 台、2 台から 3 台へと変更されました。ただし、それ以外は同じトポロジが維持されます。
.gif "この環境のファーム トポロジの図")
データセットとディスク ジオメトリ
テスト ファームには、5 個の異なるサイズのコンテンツ データベースに分散した約 1.62 テラバイトのコンテンツが挿入されました。次の表で、この分散について説明します。
| コンテンツ データベース | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
コンテンツ データベースのサイズ |
36 GB |
135 GB |
175 GB |
1.2 テラバイト |
75 GB |
サイトの数 |
44 |
74 |
9 |
9 |
222 |
Web の数 |
1544 |
2308 |
2242 |
2041 |
1178 |
RAID 構成 |
0 |
0 |
0 |
0 |
0 |
MDF のスピンドル数 |
1 |
1 |
5 |
3 |
1 |
LDF のスピンドル数 |
1 |
1 |
1 |
1 |
1 |
トランザクション ミックス
トランザクション ミックスに関する重要なメモを以下に示します。
個人用サイトは、部門ポータルで準備されていません。また、個人用サイトをサポートする User Profile Service もファームで実行されていません。トランザクション ミックスに、個人用サイトのページ/Web サービスのヒット、または Outlook Social Connector に関連するトラフィックは含まれません。
テスト ミックスに、ドキュメントの共同編集で生成されるトラフィックは含まれません。
テスト ミックスに検索クロールからのトラフィックは含まれません。ただし、これはテストで考慮されました。グリーン ゾーンの定義を変更し、SQL Server CPU 使用率を標準の 50% ではなく 40% にして、検索クロール用に 10% を確保しました。同様に、最大 RPS の条件として、80% の SQL Server CPU を使用しました。
次の表に、トランザクション ミックス全体を示します。パーセンテージの合計は 100 になります。
| 機能またはサービス | 操作 | 読み取り/書き込み | ミックスの割合 |
|---|---|---|---|
ECM |
静的ファイルを取得する |
読み取り |
8.93% |
ホーム ページを表示する |
読み取り |
1.52% |
|
Microsoft InfoPath |
アップサイズ リスト アイテムおよび新しいフォームを表示/編集する |
読み取り |
0.32% |
[名前を付けて保存] を使用してファイルをダウンロードする |
読み取り |
1.39% |
|
Microsoft OneNote 2010 |
Microsoft Office OneNote 2007 ファイルを開く |
読み取り |
13.04% |
検索 |
OSSSearch.aspx または SearchCenter を検索する |
読み取り |
4.11% |
ワークフロー |
自動開始ワークフローを開始する |
書き込み |
0.35% |
Microsoft Visio |
Visio ファイルを PMG/XAML 形式でレンダリングする |
読み取り |
0.90% |
Office Web アプリケーション - PowerPoint |
Microsoft PowerPoint をレンダリングし、6 個のスライドをスクロールする |
読み取り |
0.05% |
Office Web アプリケーション - Word |
Microsoft Word ドキュメントを PNG/Silverlight 形式でレンダリングし、スクロールする |
読み取り |
0.24% |
Microsoft SharePoint Foundation |
リスト – アイテムをチェックアウトした後にチェックインする |
書き込み |
0.83% |
リスト - リストを取得する |
読み取り |
0.83% |
|
リスト - Outlook 同期を行う |
読み取り |
1.66% |
|
リスト - リスト アイテムの変更を取得する |
読み取り |
2.49% |
|
リスト - リスト アイテムを更新し、新しいアイテムを追加する |
書き込み |
4.34% |
|
ビューとビューのコレクションを取得する |
読み取り |
0.22% |
|
Web を取得する |
読み取り |
1.21% |
|
アクセス拒否されるページを参照する |
読み取り |
0.07% |
|
リスト フィードを参照用に表示する |
読み取り |
0.62% |
|
一覧表示を参照する |
読み取り |
0.03% |
|
default.aspx (ホーム ページ) を参照する |
読み取り |
1.70% |
|
ドキュメントをドキュメント ライブラリにアップロードするのを参照する |
書き込み |
0.05% |
|
リスト/ライブラリの既定のビューを参照する |
読み取り |
7.16% |
|
DAV を使用し、ドキュメント ライブラリのドキュメントを削除する |
書き込み |
0.83% |
|
DAV を使用し、ドキュメント ライブラリからドキュメントを取得する |
読み取り |
6.44% |
|
DAV を使用し、ドキュメント ライブラリのドキュメントのロックとロック解除を行う |
書き込み |
3.32% |
|
DAV を使用し、リストに対して Propfind を実行する |
読み取り |
4.16% |
|
DAV を使用し、サイトに対して Propfind を実行する |
読み取り |
4.16% |
|
FPSE を使用し、ドキュメントを一覧表示する |
読み取り |
0.91% |
|
FPSE を使用し、ドキュメントをアップロードする |
書き込み |
0.91% |
|
サイトのすべての コンテンツ ページを参照する |
読み取り |
0.03% |
|
リストまたは Wiki の RSS フィードを表示する |
読み取り |
2.03% |
|
Excel Services |
小さい/大きい Excel ファイルをレンダリングする |
読み取り |
1.56% |
ワークスペース |
WXP - Cobalt 内部プロトコル |
読み取り |
23.00% |
WXP を使用した完全ファイル アップロード |
書き込み |
0.57% |
結果と分析
このセクションでは、テスト方法と結果の概要について説明し、標準的な部門ポータルの容量計画に関するガイダンスを示します。
1x1 ファーム構成からの結果
結果のまとめ
1 台の Web サーバーと 1 台のデータベース サーバーのファームでは、同じコンピューターが、Web サーバーの操作に加えてアプリケーション サーバーとしても機能していました。このコンピューター (依然として Web サーバーと呼ぶ) が明らかにボトルネックでした。ここでのデータに示されているとおり、前述のトランザクション ミックスを使用し、ファームのユーザー ロードが 125 ユーザーのときに、Web サーバーの CPU 使用率が 86% 前後に達しました。この時点で、ファームは 101.37 の最大 RPS を示しました。
小さいユーザー ロードでも、Web サーバーの使用率は常に非常に高く、このファームを正常なファームとみなすことはできませんでした。テストで使用したワークロードとデータセットに関して、この構成を実際の展開として使用することはお勧めできません。
"グリーン ゾーン" の定義に従うと、このファームに "グリーン ゾーン" は実際に存在しません。このファームは、小さいロードでも、常にストレスを受けている状態です。"最大ゾーン" に関しては、最小のロード (ファームは "最大ゾーン" であった) で、RPS は 75 でした。
アプリケーション サーバーとしても機能する Web サーバーの二重機能のため Web サーバーがボトルネックになっていました。したがって、次の反復では、アプリケーション サーバーの役割を独自のコンピューターに分離しました。
パフォーマンス カウンターとグラフ
次の表は、1x1 ファームのテスト中にユーザー ロードの各段階で取得された各種パフォーマンス カウンターを示しています。
| ユーザー ロード | 50 | 75 | 100 | 125 |
|---|---|---|---|---|
RPS |
74.958 |
89.001 |
95.79 |
101.37 |
待機時間 |
0.42 |
0.66 |
0.81 |
0.81 |
Web サーバー CPU |
79.6 |
80.1 |
89.9 |
86 |
アプリケーション サーバー CPU |
該当なし |
該当なし |
該当なし |
該当なし |
データベース サーバー CPU |
15.1 |
18.2 |
18.6 |
18.1 |
75 パーセンタイル (秒) |
0.3 |
0.35 |
0.55 |
0.59 |
95 パーセンタイル (秒) |
0.71 |
0.77 |
1.03 |
1 |
次のグラフは、1x1 構成での RPS と待機時間の結果を示しています。
.gif "1x1 スケールでの RPS と待機時間を示す図")
次のグラフは、1x1 構成でのパフォーマンス カウンター データを示しています。
.gif "1x1 スケールでのパフォーマンス カウンターを示す図")
1x1x1 ファーム構成からの結果
結果のまとめ
1 台の Web サーバー、1 台のアプリケーション サーバー、および 1 台のデータベース サーバーのファームでは、Web サーバーがボトルネックでした。このセクションのデータに示されているとおり、前述のトランザクション ミックスを使用し、ファームのユーザー ロードが 150 ユーザーのときに、Web サーバーの CPU 使用率が 85% 前後に達しました。この時点で、ファームは 124.1 の最大 RPS を示しました。
この構成で達成された "グリーン ゾーン" の RPS は 99、75 パーセンタイルの待機時間は 0.23 秒、Web サーバーの CPU 使用率は 56% 前後でした。これは、このファームは 99 前後の RPS を正常に達成できることを示します。このファームで達成された "最大ゾーン" の RPS は 123、待機時間は 0.25 秒、Web サーバーの CPU 使用率は 85% 前後でした。
Web サーバーの CPU がこの反復のボトルネックであったため、次の反復では別の Web サーバーを追加してボトルネックを取り除きました。
パフォーマンス カウンターとグラフ
次の表は、1x1x1 ファームのテスト中にユーザー ロードの各段階で取得された各種パフォーマンス カウンターを示しています。
| ユーザー ロード | 25 | 50 | 75 | 100 | 125 | 150 |
|---|---|---|---|---|---|---|
RPS |
53.38 |
91.8 |
112.2 |
123.25 |
123.25 |
124.1 |
待機時間 |
34.2 |
56 |
71.7 |
81.5 |
84.5 |
84.9 |
Web サーバー CPU |
23.2 |
33.8 |
34.4 |
32 |
30.9 |
35.8 |
アプリケーション サーバー CPU |
12.9 |
19.7 |
24.1 |
25.2 |
23.8 |
40.9 |
データベース サーバー CPU |
0.22 |
0.23 |
0.27 |
0.32 |
0.35 |
0.42 |
75 パーセンタイル (秒) |
0.54 |
0.52 |
0.68 |
0.71 |
0.74 |
0.88 |
次のグラフは、1x1x1 構成での RPS と待機時間の結果を示しています。
.gif "1x1x1 スケールでの RPS と待機時間を示す図")
次のグラフは、1x1x1 構成でのパフォーマンス カウンター データを示しています。
.gif "1x1x1 スケールでのパフォーマンス カウンターを示す図")
2x1x1 ファーム構成からの結果
結果のまとめ
2 台の Web サーバー、1 台のアプリケーション サーバー、および 1 台のデータベース サーバーのファームでは、Web サーバーがボトルネックでした。このセクションのデータに示されているとおり、前述のトランザクション ミックスを使用し、ファームのユーザー ロードが 200 ユーザーのときに、Web サーバーの CPU 使用率が 76% 前後に達しました。この時点で、ファームは 318 の最大 RPS を示しました。
この構成で達成された "グリーン ゾーン" の RPS は 191、75 パーセンタイルの待機時間は 0.37 秒、Web サーバーの CPU 使用率は 47% 前後でした。これは、このファームは 191 前後の RPS を正常に達成できることを示します。このファームで達成された "最大ゾーン" の RPS は 291、待機時間は 0.5 秒、Web サーバーの CPU 使用率は 75% 前後でした。
Web サーバーの CPU がこの反復のボトルネックであったため、次の反復では別の Web サーバーを追加してボトルネックを取り除きました。
パフォーマンス カウンターとグラフ
次の表は、2x1x1 ファームのテスト中にユーザー ロードの各段階で取得された各種パフォーマンス カウンターを示しています。
| ユーザー ロード | 40 | 80 | 115 | 150 | 175 | 200 |
|---|---|---|---|---|---|---|
RPS |
109 |
190 |
251 |
287 |
304 |
318 |
待機時間 |
0.32 |
0.37 |
0.42 |
0.49 |
0.54 |
0.59 |
Web サーバー CPU |
27.5 |
47.3 |
61.5 |
66.9 |
73.8 |
76.2 |
アプリケーション サーバー CPU |
17.6 |
29.7 |
34.7 |
38 |
45 |
45.9 |
データベース サーバー CPU |
21.2 |
36.1 |
43.7 |
48.5 |
52.8 |
56.2 |
75 パーセンタイル (秒) |
0.205 |
0.23 |
0.27 |
0.3 |
0.305 |
0.305 |
95 パーセンタイル (秒) |
0.535 |
0.57 |
0.625 |
0.745 |
0.645 |
0.57 |
次のグラフは、2x1x1 構成での RPS と待機時間の結果を示しています。
.gif "2x1x1 スケールでの RPS と待機時間を示す図")
次のグラフは、2x1x1 構成でのパフォーマンス カウンター データを示しています。
.gif "2x1x1 スケールでのパフォーマンス カウンターを示す図")
3x1x1 ファーム構成からの結果
結果のまとめ
3 台の Web サーバー、1 台のアプリケーション サーバー、および 1 台のデータベース サーバーのファームでは、最終的に、データベース サーバーの CPU がボトルネックでした。このセクションのデータに示されているとおり、前述のトランザクション ミックスを使用し、ファームのユーザー ロードが 226 ユーザーのときに、データベース サーバーの CPU 使用率が 76% 前後に達しました。この時点で、ファームは 310 の最大 RPS を示しました。
この構成で達成された "グリーン ゾーン" の RPS は 242、75 パーセンタイルの待機時間は 0.41 秒、データベース サーバーの CPU 使用率は 44% 前後でした。これは、このファームは 242 前後の RPS を正常に達成できることを示します。このファームで達成された "最大ゾーン" の RPS は 318、待機時間は 0.5 秒、データベース サーバーの CPU 使用率は 75% 前後でした。
これは、一連の最後の構成でした。
パフォーマンス カウンターとグラフ
次の表は、3x1x1 ファームのテスト中にユーザー ロードの各段階で取得された各種パフォーマンス カウンターを示しています。
| ユーザー ロード | 66 | 103 | 141 | 17 | 202 | 226 |
|---|---|---|---|---|---|---|
RPS |
193.8 |
218.5 |
269.8 |
275.5 |
318.25 |
310 |
待機時間 |
0.3 |
0.41 |
0.47 |
0.58 |
0.54 |
0.78 |
Web サーバー CPU |
33 |
38.3 |
45.8 |
43.3 |
51 |
42.5 |
アプリケーション サーバー CPU |
28 |
32.6 |
46.5 |
40 |
45.1 |
43.7 |
データベース サーバー CPU |
41.6 |
44.2 |
52.6 |
48 |
61.8 |
75 |
75 パーセンタイル (秒) |
0.22 |
0.24 |
0.30 |
0.65 |
0.78 |
0.87 |
95 パーセンタイル (秒) |
0.49 |
0.57 |
0.72 |
1.49 |
0.51 |
1.43 |
次のグラフは、3x1x1 構成での RPS と待機時間の結果を示しています。
.gif "3x1x1 スケールでの RPS と待機時間を示す図")
次のグラフは、3x1x1 構成でのパフォーマンス カウンター データを示しています。
.gif "3x1x1 スケールでのパフォーマンス カウンターを示す図")
比較
実行された反復テストから、構成が最大ゾーンまたはグリーン ゾーンに入るポイントが見つかりました。以下の表にそのポイントを示します。
このセクションの表とグラフは、前述のすべての結果の概要を示しています。
| トポロジ | 1x1 | 1x1x1 | 2x1x1 | 3x1x1 |
|---|---|---|---|---|
最大 RPS |
75 |
123 |
291 |
318 |
グリーン ゾーン RPS |
該当なし |
99 |
191 |
242 |
最大待機時間 |
0.29 |
0.25 |
0.5 |
0.5 |
グリーン ゾーンの待機時間 |
0.23 |
0.23 |
0.37 |
0.41 |
次のグラフは、各構成の RPS の概要を示しています。
.gif "各スケールでの RPS の比較を示す図")
次のグラフは、各構成の待機時間の概要を示しています。
.gif "すべてのスケールでの待機時間の比較")
ディスク I/O に関するメモ
このドキュメントの推奨事項は、ディスク I/O ベースのボトルネックが考慮されないまま規定されました。ただし、傾向を観察することも有益です。ここに数字を示します。
| 構成 | 1x1 | 1x1x1 | 2x1x1 | 3x1x1 |
|---|---|---|---|---|
最大 RPS |
75 |
154 |
291 |
318 |
読み取り/秒 |
38 |
34 |
54 |
58 |
書き込み/秒 |
135 |
115 |
230 |
270 |
テストは 1 時間間隔で実行されました。また、テストでは、サイト/Web/ドキュメント ライブラリなどの固定セットのみが使用されました。したがって、SQL Server はすべてのデータをキャッシュできました。つまり、テストでは、読み取り I/O がほとんど発生しませんでした。書き込み I/O 操作のほうが読み取りよりも多くなっています。これは、テスト方法による人為的な結果であり、実際の展開を適切に表していないことに注意することが重要です。通常の部門ポータルのほとんどで、書き込み操作の 3 ～ 4 倍の読み込み操作が発生します。
次のグラフは、各 RPS の I/O の概要を示しています。
.gif "すべてのスケールでの IOP を示す図")
検索の増分クロールを使用したテスト
前述のとおり、ここまでのすべてのテストは、検索クロールのトラフィックなしで実行されました。進行中の検索クロールがファームのパフォーマンスにどのような影響を与える可能性があるかについて、情報を提供するために、検索クロールのトラフィックをミックスに含めて、最大ユーザー RPS および対応するユーザー待機時間を見つけることにしました。独立した Web サーバーを 3x1x1 ファームに追加し、クロール ターゲットとして指定しました。3x1x1 で示された元の RPS と比較して RPS が 17% 低下したことが確認されました。
同じファームでの別のテストでは、リソース ガバナーを使用して、検索クロールで利用可能なリソースを 10% に制限しました。検索で使用されるリソースが少なくなると、ファームの最大 RPS が 6% 上昇することが確認されました。
| ベースライン 3x1x1 | 増分クロールのみ | リソース ガバナーなし | 10% リソース ガバナー | |
|---|---|---|---|---|
RPS |
318 |
該当なし |
276 |
294.5 |
ベースラインの RPS との違い (%) |
0% |
該当なし |
83% |
88% |
データベース サーバー CPU (%) |
83.40 |
8.00 |
86.60 |
87.3 |
SA データベース サーバー CPU (%) |
3.16 |
2.13 |
3.88 |
4.2 |
Web サーバー CPU (%) |
53.40 |
0.30 |
47.00 |
46.5 |
アプリケーション サーバー CPU (%) |
22.10 |
28.60 |
48.00 |
41.3 |
クロール Web サーバー CPU (%) |
0.50 |
16.50 |
15.00 |
12.1 |
次のグラフは、増分検索クロールを有効にしたテストの結果を示しています。
.gif "検索実行時の 1 秒あたりの要求数")
重要
ここでは、コンテンツに対する変更が少ないファームにおける増分クロールについてのみ説明しています。フル検索クロールを実行するには、10% のリソース使用率は不十分であることに注意することが重要です。また、非常に多くの変更がある場合、さらに低下する場合があることも判明しています。フル検索クロールを実行する場合や、各クロール間で大量のコンテンツ変更がファームで一般的に行われる場合は、リソース使用率を 10% に制限しないでください。
結果と推奨事項のまとめ
テストしたすべての構成からの結果は、以下のように言い換えることができます。
テストで選択した構成、データセット、およびテスト ワークロードでは、SQL Server が CPU でボトルネックになるまでに、最大 3 台の Web サーバーまでスケール アウトできました。到達できた絶対最大 RPS は 318 前後の値でした。
Web サーバーを追加するたびに、RPS はほぼ直線的に増加しました。このことから、SQL Server がボトルネックになっていない限り、Web サーバーを追加することで RPS をさらに増加できることが推測されます。
SQL Server のボトルネックに近づいても、待機時間に大きな影響はありません。
増分検索クロールは、構成によってもたらされる RPS に直接影響します。その影響は、リソース ガバナーを使用して最小限に抑えることができます。
これらの結果を使用して、いくつかの推奨事項をここにまとめました。これらは、部門ポータルで RPS を増加する必要がある場合にさらに大きな規模を実現する方法についての推奨事項です。
1x1 ファームでは、最大 75 RPS を達成できます。ただし、このファームは常にストレスを受けています。この構成は、運用環境の部門ポータルとしてお勧めできません。
コンテンツ データベースとサービス データベースを SQL Server の別々のインスタンスに分離します。テストで使用されたテスト ワークロードでは、SQL Server が CPU でボトルネックになったときに、サービス データベースへのトラフィックは 3% のみでした。つまり、この手順によって、表示されたものよりも若干優れたスケールアウトが達成された可能性があります。ただし、一般的に、コンテンツ データベースとサービス データベースの分離によるスケール アウトの増加は、ファーム内のサービス データベースへのトラフィックに直接比例します。
個々のコンテンツ データベースを SQL Server の別々のインスタンスに分離します。テストで使用したデータセットには 5 つのコンテンツ データベースがあり、そのすべてが SQL Server の同じインスタンスに配置されていました。異なるコンピューターにコンテンツ データベースを分離することで、CPU の使用が複数のコンピューターに分散されます。したがって、RPS の数字が大幅に増加します。
最終的に、SQL Server が CPU でボトルネックになった場合、CPU を SQL Server に追加することで、ファームの持つ RPS の可能性をほぼ直線的に増加できます。
これらの結果をユーザーの展開に転換する方法
この記事では、RPS と待機時間によって測定されたとおりの結果について説明しましたが、これらの結果が実際の世界にどのように適用されるのでしょうか。Microsoft 内部の部門ポータルからの経験に基づいたある数学をここに示します。
グループ作業を活発に行う約 8,000 人の従業員をサポートする Microsoft の部門ポータルの平均 RPS は 110 です。1 ユーザーあたりの RPS 比率は約 72 (つまり、8,000/110) になります。この比率と、前述の結果を使用して、特定のファーム構成で何人のユーザーを正常にサポートできるかを見積もることができます。
| ファーム構成 | "グリーン ゾーン" RPS | サポート可能なユーザー数の概数 |
|---|---|---|
1x1x1 |
99 |
7128 |
2x1x1 |
191 |
13452 |
3x1x1 |
242 |
17424 |
もちろん、これらの数字を直接的に適用できるのは、ユーザのトランザクション ミックスとハードウェアがテストで使用されたものと正確に一致する場合のみです。ユーザーの部門ポータルの利用パターンは異なる場合があります。したがって、比率を直接的に適用することはできません。ただし、比率はおよそ適用可能であると予想しています。
執筆者について
Gaurav Doshi は、Microsoft での SharePoint Server のプログラム マネージャーです。
Raj Dhrolia は、Microsoft での SharePoint Server のソフトウェア テスト エンジニアです。
Wayne Roseberry は、Microsoft での SharePoint Server のプリンシパル テスト リードです。