Microsoft SharePoint Server 2010 ベースの部門別ポータルのキャパシティプランニングとサイズ変更

このドキュメントは現状有姿で提供され、このドキュメント (URL などのインターネット Web サイトにある参照先を含む) に記載されている情報および見解は、将来予告なしに変更することがあります。これを使用する責任はお客様ご自身にあります。このドキュメントに記載されている例の一部は、例示のみを目的としており、架空のものです。実在する事物とは一切関係ありません。このドキュメントは、あらゆるマイクロソフト製品に対する何らかの知的財産権をお客様に付与するものではありません。このドキュメントは、内部的な参照目的にのみコピーおよび使用することができます。

© 2010 Microsoft Corporation. All rights reserved.

Microsoft SharePoint Server 2010 ベースの部門別ポータルのキャパシティプランニングとサイズ変更

Gaurav Doshi、Raj Dhrolia、Wayne RoseberryMicrosoft Corporation2010 年 2 月適用 : Office SharePoint Server 2010概要 : このホワイト ペーパーは、SharePoint Server 2010 ベースの部門別ポータルのパフォーマンスとキャパシティプランニングのガイダンスを提供します。

ハードウェア、ファーム トポロジ、構成などのテスト環境の仕様

テスト ファームのデータ セット

類似した環境を展開するために必要なハードウェア、トポロジ、構成を決定する方法と、適切な処理能力とパフォーマンス特性を得るために環境を最適化する方法に関するテスト データと推奨事項

目次はじめに..........................................................................................................................4

シナリオ......................................................................................................................4仮定と前提条件.............................................................................................................4

テストのセットアップ......................................................................................................6ハードウェア................................................................................................................6

ソフトウェア................................................................................................................6トポロジと構成.............................................................................................................7データ セットとディスク ジオメトリ..............................................................................7トランザクション ミックス............................................................................................8

結果と分析.....................................................................................................................10テストの手法..............................................................................................................10反復の結果 (1 X 1、1 X 1 X 1、2 X 1 X 1、3 X 1 X 1)........................................................11

1 X 1 ファーム構成..................................................................................................111 X 1 X 1 ファーム構成............................................................................................122 X 1 X 1 ファーム構成............................................................................................143 X 1 X 1 ファーム構成............................................................................................16

比較...........................................................................................................................18検索増分クロールを使用したテスト..............................................................................20結果と推奨事項のまとめ..............................................................................................21

はじめにシナリオ このドキュメントは、典型的な部門別ポータルのキャパシティプランニングについて、そのガイダンスを提供するためのテストの手法と結果の概要を示します。部門別ポータルは、主にチームで共同作業と何らかのコンテンツ公開を行う Microsoft® SharePoint® Server 2010 展開の 1 つの方法です。このドキュメントの “部門” とは、従業員が 1,000 ～ 10,000 人の会社内の 1 つの組織を仮定しています。

シナリオが変われば要件も異なるため、実際のハードウェアと環境で追加のテストを行って、このガイダンスを補完することが重要です。

このドキュメントを読み終わると、次の方法を理解できます。 必要な規模のユーザー数、負荷、および有効にする機能をサポートするために必要なハード

ウェアの見積もり 最適な信頼性と効率性を備えた物理的論理的トポロジの設計。（高可用性/障害回復について

は、このドキュメントではカバーしていません。 ） 部門別ポータル展開の RPS に対する進行中の検索クロールの影響

このドキュメントを読む前に、次の内容 (英語) を読む必要があります。 『Capacity Planning and Sizing for Microsoft SharePoint 2010 Products and

Technologies (Microsoft SharePoint 2010 製品とテクノロジの処理能力の計画とサイズ)』

『Office SharePoint Server 2010 Software Boundaries (Office SharePoint Server 2010 ソフトウェアの制限)』

また、次も参照することをお勧めします。 「Performance and capacity technical case studies ( パフォーマンスと処理能力の技術

ケース スタディ ) 」ページ (http://technet.microsoft.com/en-us/library/cc261716(office.14).aspx、英語) にある『Microsoft SharePoint Server 2010 Departmental Collaboration Environment (Microsoft SharePoint Server 2010 部門コラボレーション環境)』ドキュメント (英語)

仮定と前提条件

このテストでは、ディスク I/O を制限要素と見なしません。利用できるスピンドルの数は無限であることを前提とします。

テストは、典型的な部門別ポータルのピーク時の使用状況のみをモデリングしています。昼夜のサイクルで見られるようなトラフィックの周期的な変化は考慮していません。したがって、一般には夜に実行するようにスケジュールされるタイマー ジョブも、トランザクション ミックスには含まれていません。

この場合は、部門別ポータル展開で実行されるカスタム コードはありません。部門別ポータルにインストールされるカスタム コードやサード パーティ ソリューションの動作は保証されません。

テストを目的としているため、すべてのサービス DB とコンテンツ DB は、Microsoft SQL Server® の同じインスタンスに置かれています。また、使用 DB は、別の SQL Server インスタンスで管理されます。

テストを目的としているため、BLOB キャッシュは有効になっています。 認証モードは NTLM です。

このテストでは、検索クロールのトラフィックは考慮されていません。ただし、進行中の検索クロールの影響を織り込むために、健全なファームの定義を変更しました。検索クロールの負荷を 10% と見なして、SQL Server のグリーン ゾーンを 40% と定義しました。同様に、最大 RPS の基準として、SQL Server CPU の 80% を使用しました。

テストのセットアップハードウェア次の表に、このテストで使用したコンピューターのハードウェア仕様を示します。テストを何回か反復する間にサーバー ファームに追加されるフロントエンド Web サーバーは、それぞれ同じ仕様に従います。

フロントエンド Web サーバー

アプリケーション サーバー

データベース サーバー

サーバー モデル PE 2950 PE 2950 Dell PE 6850プロセッサ 2px4c@2.33GH

z2px4c@2.33GHz 4px4c@ 3.19GHz

RAM 8 GB 8 GB 32 GBNIC の数 2 2 1NIC 速度 1 ギガビット 1 ギガビット 1 ギガビットロード バランサーの種類

F5 - ハードウェア ロード バランサー

該当なし 該当なし

ULS ログ レベル ミディアム ミディアム 該当なし

表 1: サーバー コンピューターのハードウェア仕様

ソフトウェア次の表に、このテスト作業で使用したサーバーにインストールされて実行されたソフトウェアの仕様を示します。

 フロントエンド Web サーバー

アプリケーション サーバー

データベース サーバー

オペレーティング システム

Windows Server® 2008 R2 x64

Windows Server 2008 R2 x64

Windows Server 2008 x64

ソフトウェア バージョン

Microsoft SharePoint 4733.1000、WAC 4733.1000

Microsoft SharePoint 4733.1000、WAC 4733.1000

SQL Server 2008 R2 CTP3

ロード バランサーの種類

F5 - ハードウェア ロード バランサー

該当なし 該当なし

ULS ログ レベル

ミディアム ミディアム 該当なし

ウイルス対策設定

無効 無効 無効

表 2: サーバー コンピューターのソフトウェア仕様

トポロジと構成次のトポロジの図は、テストに使用したハードウェア設定を示します。テストを反復する間にフロントエンド Web サーバーの数を 1 から 2、3 へと変更しましたが、それ以外のトポロジは同じです。

図 1: ファームの構成テスト環境に設定したサービスについては、上の図を参照してください。ユーザー プロファイル サービスや Web 解析などのその他のサービスは設定していません。

データ セットとディスク ジオメトリ テスト ファームには、約 1.62 テラバイトのコンテンツが、異なるサイズの 5 つのコンテンツ データベースに分散して配置されました。次の表に、データの分散方法を示します。

コンテンツ DB #

1 2 3 4 5

コンテンツ DBサイズ

36 GB 135 GB 175 GB 1.2 TB 75 GB

サイトの数 44 74 9 9 222Web の数 1544 2308 2242 2041 1178RAID の構成 0 0 0 0 0MDF のスピンドルの数

1 1 5 3 1

LDF のスピンドルの数

1 1 1 1 1

表 3: データ セットとディスク ジオメトリ

トランザクション ミックス重要事項

この部門別ポータルでは、個人用サイトを設定していません。個人用サイトをサポートするユーザー プロファイル サービスもファームで実行されません。個人サイト ページ/Web サービスのヒットまたは Outlook Social Connector に関連するトラフィックは、トランザクション ミックスに含まれません。

ドキュメントの共同作成によって生成されるトラフィックは、テスト ミックスに含まれません。

検索クロールのトラフィックは、テスト ミックスに含まれません。ただし、検索クロール用に 10% の余裕を見て、SQL Server CPU 使用率のグリーン ゾーンの定義を標準の 50% から 40% に変更したため、クロールはテストに織り込まれています。同様に、MAX RPS の基準として、SQL Server CPU の 80% を使用しました。

次の表に、トランザクション ミックスの概要を示します。

機能/サービス 操作 read/writeミックス内の割合

ECM 静的ファイルの取得 R 8.93%ホーム ページの表示 R 1.52%

Microsoft Infopath®

アップサイズ リスト項目と新しいフォームの表示/編集 R 0.32%[名前を付けて保存] を使用したファイルのダウンロード R 1.39%

Microsoft OneNote® Office 12 OneNote ファイルを開く R 13.04%

検索このサイト、このリスト（OSSSearch.aspx） または Search Center からの検索 R 4.11%

ワークフロー 自動起動ワークフローの開始 W 0.35%Microsoft Visio® PNG/XAML での VISIO ファイルの表示 R 0.90%Office Web App - PowerPoint

Microsoft PowerPoint® を表示、6 枚目のスライドにスクロール R 0.05%

Office Web App - Word

PNG/Silverlight での Microsoft Word ドキュメントの表示とスクロール R 0.24%

Microsoft SharePoint Foundation

リスト - 項目のチェックアウトおよびチェックイン W 0.83%リスト - リストの取得 R 0.83%リスト - Outlook 同期 R 1.66%リスト - リスト項目の変更の取得 R 2.49%リスト - リスト項目の更新と新しい項目の追加 W 4.34%ビューの表示とビューの収集 R 0.22%Web ブラウザの表示 R 1.21%アクセス拒否ページの参照 R 0.07%リスト フィードの表示と参照 R 0.62%一覧表示の参照 R 0.03%default.aspx (Office 12 または Office 14 のホーム ページ) の参照 R 1.70%ドキュメントを参照してドキュメント ライブラリにアップロード W 0.05%リスト/ライブラリの既定のビューの参照 R 7.16%

DAV を使用したドキュメント ライブラリ内のドキュメントの削除 W 0.83%DAV を使用したドキュメント ライブラリからのドキュメントの取得 R 6.44%DAV を使用したドキュメント ライブラリ内のドキュメントのロックおよびアンロック W 3.32%DAV を使用したリストの Propfind R 4.16%DAV を使用したサイトの Propfind R 4.16%FPSE を使用したドキュメントの一覧 R 0.91%FPSE を使用したドキュメントのアップロード W 0.91%すべてのサイト コンテンツ ページの参照 R 0.03%リストまたは Wiki の RSS フィードの表示 R 2.03%

Excel Service 大小 Excel ファイルの表示 R 1.56%ワークスペース WXP - Cobalt インターナル プロトコル R 23.00%

WXP を使用した全ファイルのアップロード W 0.57%合計 100%

表 4: テストのトランザクション ミックス

結果と分析テストの手法パフォーマンス テストの実行には、Visual Studio Team System for Test 2008 SP2 を使用しました。このテストの目標は、各トポロジのグリーン ゾーン、MAX ゾーン、およびその間のさまざまなシステム段階におけるパフォーマンスの特性を見つけ出すことです。“MAX ゾーン” と “グリーン ゾーン” の詳細な定義は、次に示すように、いくつかのパフォーマンス カウンターの値として与えられます。ただし、一般には、“MAX ゾーン” のブレークポイント付近で実行されているファーム構成はストレスがかかっていると考えられ、“グリーン ゾーン” のブレークポイント付近で実行されているファーム構成は健全であると考えられます。

MAX RPS の基準o スロットルがオン、503 エラーなしo 失敗率が 0.1% 未満o 75 パーセンタイルの遅延時間が 1 秒未満o 検索クロールを考慮して SQL Server CPU <= 75%o すべてのフロントエンド Web サーバー CPU <=75%

“グリーン ゾーン” の基準o 75 パーセンタイルの遅延時間が 0.5 秒未満o フロントエンド Web サーバー CPU が 50% 未満o SQL Server CPU が 40% 未満 (10% は検索クロールを考慮)o アプリケーション サーバー CPU が 50% 未満o 失敗率が 0.01% 未満

メモ: 検索クロールの影響を織り込むために、検索クロールの負荷を 10% と見なして、SQL のグリーン ゾーンを 40% と定義しました。同様に、最大 RPS の基準として、SQL Server CPU の 75% を使用しました。

テストの手法として、最も基本的なファーム構成から始めて、一連のテストを行いました。最初のテストでは、徐々にシステムの負荷を増やして、パフォーマンスの特性を監視しました。このテストから、さまざまなユーザー負荷でのスループットや遅延を得ると共に、システムのボトルネックを特定しました。このデータを取得したところで、ファームがグリーン ゾーンと MAX ゾーンの特性を示すユーザー負荷を特定しました。事前に指定した一定のユーザー負荷で長時間のテストを何回か個別に行いました。このテストで、このファーム構成がそれぞれのユーザー負荷で長期間持続してグリーン ゾーンと MAX ゾーンのパフォーマンスを提供できることを確認しました。 その後、次の構成のテストを行う際に、前の実行で特定したボトルネックがなくなるようにシステムをスケールアウトします。SQL Server の CPU がボトルネックになるまでこの方法を繰り返します。 1 台のフロントエンド Web サーバー/アプリケーション サーバーと 1 台の SQL Server から成る最小ファーム構成から開始しました。何回かの反復を経て、最終的に 3 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、1 台の SQL Server のファーム構成で終了しました。ここで、SQL Server の CPU が上限を超えました。各反復で構成のグリーン ゾーンと MAX ゾーンを確立するために実行したテストの要約とグラフを次に示します。その後、さまざまな反復でグリーン ゾーンと MAX ゾーンを比較して、推奨事項を導き出します。 SharePoint Admin Toolkit チームは、LTK (Load Test Toolkit) というツールを作成しました。このツールは、ユーザーがダウンロードして使用できるように公開されています。

反復の結果 (1 X 1、1 X 1 X 1、2 X 1 X 1、3 X 1 X 1)1 X 1 ファーム構成結果の概要

- 1 台のフロントエンド Web サーバーと 1 台の SQL Server のファームでは、同じコンピューターがフロントエンド Web サーバーの作業の他に、アプリケーション サーバーとしても動作します。明らかにこのコンピューター (引き続きフロントエンド Web サーバーと記載) がボトルネックになりました。次のデータにあるように、このドキュメントの前半で説明したトランザクション ミックスを使用してファームに 125 ユーザーの負荷が与えられると、フロントエンド Web サーバー CPU は約 86% の使用率に達しました。この時点で、ファームは 101.37 の MAX RPS を示しています。

- 小さなユーザー負荷でも、フロントエンド Web サーバーの使用率は常に非常に高く、このファームを健全なファームと見なすことはできませんでした。テストに使用した負荷とデータ セットに対して、この構成は実際の展開としては推奨されません。

- “グリーン ゾーン” の定義に従うと、このファームには、実際には “グリーン ゾーン” はありません。負荷が小さい場合でも、常にストレスにさらされています。“MAX ゾーン” については、ファームが “MAX ゾーン” になる最小の負荷で、RPS 75 でした。

- フロントエンド Web サーバーがアプリケーション サーバーと二重の役割を持ってボトルネックになったため、次の反復では、アプリケーション サーバーを専用のコンピューターに分離しました。

パフォーマンス カウンターとグラフさまざまなユーザー負荷段階で 1 X 1 ファームのテスト中にキャプチャされたパフォーマンス カウンターを次に示します。

ユーザー負荷 50 75 100 125RPS 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

該当なし 該当なし 該当なし 該当なし

SQL Server CPU 15.1 18.2 18.6 18.175 パーセンタイル [秒] 0.3 0.35 0.55 0.5995 パーセンタイル [秒] 0.71 0.77 1.03 1

表 5: 1 X 1 ファーム構成のパフォーマンス カウンター

グラフ 1: 1 X 1 構成の RPS と遅延

グラフ 2: 1 X 1 構成のパフォーマンス カウンター1 X 1 X 1 ファーム構成結果の概要

- 1 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、1 台の SQL Server のファームでは、フロントエンド Web サーバー がボトルネックになりました。次のデータにあるように、このドキュメントの前半で説明したトランザクション ミックスを使用してファームに 150 ユーザーの負荷が与えられると、フロントエンド Web サーバー CPU は約 85% の使用率に達しました。この時点で、ファームは 124.1 の MAX RPS を示しています。

- この構成では、RPS が 99、75 パーセンタイルの遅延が 0.23 秒、フロントエンド Web サーバーの CPU が 56% 程度の使用率の “グリーン ゾーン” が提供されました。このことは、このファームが健全に約 99 の RPS を提供できることを意味します。このファームで提供される “MAX ゾーン” の RPS は 123 で、遅延は 0.25 秒、フロントエンド Web サーバーの CPU は約 85% 程度の使用率になります。

- この反復ではフロントエンド Web サーバーの CPU がボトルネックだったため、次の反復では、さらにフロントエンド Web サーバーを追加しました。

-パフォーマンス カウンターとグラフさまざまなユーザー負荷段階で 1 X 1 X 1 ファームのテスト中にキャプチャされたパフォーマンス カウンターを次に示します。

ユーザー負荷 25 50 75 100 125 150RPS 53.38 91.8 112.2 123.25 123.25 124.1フロントエンド Web サーバー CPU

34.2 56 71.7 81.5 84.5 84.9

アプリケーション サーバー CPU

23.2 33.8 34.4 32 30.9 35.8

SQL Server CPU

12.9 19.7 24.1 25.2 23.8 40.9

75 パーセンタイルの遅延 [秒]

0.22 0.23 0.27 0.32 0.35 0.42

95 パーセンタイルの遅延 [秒]

0.54 0.52 0.68 0.71 0.74 0.88

表 6: 1 X 1 X 1 構成のパフォーマンス カウンター

グラフ 3: 1 X 1 X 1 構成の RPS と遅延

グラフ 4: 1 X 1 X 1 構成のパフォーマンス カウンター2 X 1 X 1 ファーム構成結果の概要

- 2 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、1 台の SQL Server のファームでは、フロントエンド Web サーバー がボトルネックになりました。次のデータにあるように、このドキュメントの前半で説明したトランザクション ミックスを使用してファームに 200 ユーザーの負荷が与えられると、フロントエンド Web サーバー CPU は約 76% の使用率に達しました。この時点で、ファームは 318 の最大 RPS を示しています。

- この構成では、RPS が 191、75 パーセンタイルの遅延が 0.37 秒、フロントエンド Web サーバーの CPU が 47% 程度の使用率の “グリーン ゾーン” が提供されました。これは、このファームが健全に約 191 の RPS を提供できることを意味します。このファームで提供される “MAX ゾーン” の RPS は 291 で、遅延は 0.5 秒、フロントエンド Web サーバーの CPU は約 75% 程度の使用率になります。

- この反復ではフロントエンド Web サーバーの CPU がボトルネックだったため、次の反復では、さらにフロントエンド Web サーバーを追加しました。

パフォーマンス カウンターとグラフさまざまなユーザー負荷段階で 2 X 1 X 1 ファームのテスト中にキャプチャされたパフォーマンス カウンターを次に示します。

ユーザー負荷 40 80 115 150 175 200RPS 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

SQL Server CPU

109 190 251 287 304 318

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

表 7: 2 X 1 X 1 構成のパフォーマンス カウンター

グラフ 5: 2 X 1 X 1 構成の RPS と遅延

グラフ 6: 2 X 1 X 1 構成のパフォーマンス カウンター3 X 1 X 1 ファーム構成結果の概要

- 3 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、1 台の SQL Server のファームでは、最終的に SQL Server の CPU がボトルネックになりました。次のデータにあるように、このドキュメントの前半で説明したトランザクション ミックスを使用してファームに 226 ユーザーの負荷が与えられると、SQL Server CPU は約 76% の使用率に達しました。この時点で、ファームは 310 の最大 RPS を示しています。

- この構成では、RPS が 242、75 パーセンタイルの遅延が 0.41 秒、SQL Server の CPU が 44% 程度の使用率の “グリーン ゾーン” が提供されました。このことは、このファームが健全に約 242 の RPS を提供できることを意味します。このファームで提供される “MAX ゾーン” の RPS は 318 で、遅延は 0.5 秒、SQL Server の CPU は 75% 程度の使用率になります。

- これは、このシリーズの最後の構成です。

パフォーマンス カウンターとグラフさまざまなユーザー負荷段階で 3 X 1 X 1 ファームのテスト中にキャプチャされたパフォーマンス カウンターを次に示します。

ユーザー負荷 66 103 141 17 202 226RPS 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

SQL Server 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

表 8: 3 X 1 X 1 構成のパフォーマンス カウンター

グラフ 7: 3 X 1 X 1 構成の RPS と遅延

グラフ 8: 3 X 1 X 1 構成のパフォーマンス カウンター

比較 実行した段階テストから、各構成が MAX ゾーンまたはグリーン ゾーンになるポイントがわかりました。このポイントを表に示します。 次の表とグラフは、上に示したすべての結果の概要です。

トポロジ 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

表 10: さまざまな構成の結果の概要

グラフ 9: さまざまな構成の RPS の概要

グラフ 10: さまざまな構成の遅延の概要ディスク I/O に関するメモこのドキュメントに記載されている推奨事項では、ディスク I/O ベースのボトルネックは考慮されていませんが、傾向を観察しておくことに意味はあります。次のような数値になりました。

構成 1x1 1x1x1 2x1x1 3x1x1最大 RPS 75 154 291 318読み込み数/秒 38 34 54 58書き取り数/秒 135 115 230 270

表 11: さまざまな構成での 1 秒あたりの I/Oテストを 1 時間実行し、固定のサイト/Web/ドキュメント ライブラリ セットのみを稼働したため、SQL Server はすべてのデータをキャッシュできました。そのため、テストで発生した読み取り IO は非常に少なくなりました。書き込み I/O 操作の方が読み取りより多いことがわかります。これはテスト手法に基づく人為的な結果であり、実際の展開をよく表すものではないことに注意してください。典型的な部門別ポータルでは、書き込み操作の 3、4 倍の読み取り操作があることが普通です。

グラフ 11: さまざまな RPS での 1 秒あたりの I/O

検索増分クロールを使用したテスト 前述のように、これまでのすべてのテストは検索クロールのトラフィックなしで実行されています。実行中の検索クロールがファームのパフォーマンスに及ぼす影響についての情報を提供するために、

トランザクション ミックスに検索クロールのトラフィックを入れて、最大エンド ユーザー RPS と、対応するエンド ユーザーの遅延を調査することにしました。検索クロールのターゲット用として、1 台の専用フロントエンド Web サーバーを 3 X 1 X 1 ファームに追加しました。3 X 1 X 1 の場合の元の RPS と比較して、RPS が 17% 低下しました。 同じファームの別のテストで、Resource Governor を使用して、検索クロールが利用できるリソースを 10% に制限しました。検索が利用するリソースが減り、ファームの最大 RPS が 6% 増加しました。

このテスト結果は次のとおりです。

ベースライン 3 X 1 X 1

増分クロールのみ

Resource Governor なし

10% Resource Governor

RPS 318 該当なし 276 294.5ベースラインとの差 (% RPS) 0% 該当なし 83% 88%SQL Server CPU  [%] 83.40 8.00 86.60 87.3SA SQL Server 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

表 12: 増分検索クロールのテスト結果

グラフ 12: 増分検索クロールのテスト結果

重要事項ここでは、コンテンツの変更があまり多くないファームの増分クロールについてのみ議論しています。10% のリソース使用量は、フル検索クロールに対しては非常に少ないことに注意してください。また、変更が非常に多い場合にも足りないことがあります。フル検索クロールを実行している場合や、一般にクロールとクロールの間のコンテンツの変化量が大きい場合は、リソースの使用量を 10% に制限することは推奨されません。

結果と推奨事項のまとめテストしたすべての構成の結果をまとめると、次のようになります。

テストに選択した構成、データ セット、およびテスト負荷では、最大 3 台のフロントエンド サーバーに拡大したところで、SQL Server の CPU にボトルネックが発生しました。この時点で得られた絶対的な最大 RPS は、約 318 でした。

フロントエンド Web サーバーの追加により、RPS はほぼ直線的に増加しました。SQL Server がボトルネックにならない限りは、フロントエンド Web サーバーを追加して RPS を増やすことができます。

SQL Server のボトルネックに近づくときに、遅延は大きな影響を受けません。 増分検索クロールは、構成から提供される RPS に直接影響を及ぼします。Resource

Governor を使用することで、この影響を最小限に抑えることができます。 この結果を参考にすると、部門別ポータルに必要な RPS が増えた場合にさらにスケールを拡大する方法として、次の推奨事項が挙げられます。 1 X 1 ファームは、最大 75 RPS を提供しますが、ほぼ常にストレスがかかっています。運

用中の部門別ポータルの構成としては推奨されません。 コンテンツ データベースとサービス データベースを別々の SQL Server に分けます。テス

トで使用した負荷では、SQL Server の CPU がボトルネックになったときに、サービス DB に送られていたトラフィックは 3% だけでした。このため、この手順では、見た目よりわずかに良好なスケーリングが実現されています。ただし、一般には、コンテンツ DB とサービス DB を分けることによるスケールの向上は、ファームのサービス DB へのトラフィックに完全に比例します。

各コンテンツ DB を別々の SQL Server インスタンスに分けます。テストで使用したデータ セットでは、5 つのコンテンツ DB をすべて SQL Server の同じインスタンスに配置しました。これらを別のコンピューターに分けることで、CPU の利用が複数のコンピューターに分散されるため、RPS 数がきわめて大きくなります。

最後に、SQL Server サーバーの CPU がボトルネックになった場合は、SQL Server に CPU を追加すると、ファームの RPS をほぼ直線的に増やすことができます。

この結果を実際の展開に活用する方法ここまでは、RPS と遅延の点から結果を説明しましたが、現実にはどう適用すればよいでしょうか。ここで、マイクロソフト社内の部門別ポータルから得られた経験に基づく計算方法があります。マイクロソフト社内のある部門別ポータルでは、約 8000 人という大勢の従業員の共同作業をサポートしながら、平均 110 の RPS が得られています。ユーザー/RPS 比は約 72 (=8000/110) です。この比率と前述の結果を使用して、特定のファーム構成が健全にサポートできるユーザー数を推測できます。

ファームの構成 “グリーン ゾーン” の RPS

サポートできるユーザーの概数

1 X 1 X 1 99 71282 X 1 X 1 191 134523 X 1 X 1 242 17424

表 13: 各構成のユーザー人口の概数

もちろん、これが直接当てはまるのは、トランザクション ミックスとハードウェアがテストで使用されたものと完全に同じ場合に限ります。実際の部門別ポータルは利用パターンが異なり、この比率を直接当てはめることはできませんが、近似的には適用可能と考えられます。