Microsoft SharePoint Server 2010 のソーシャル環境: ラボの研究
適用先: SharePoint Server 2010
トピックの最終更新日: 2016-11-30
この記事では、Microsoft SharePoint Server 2010 に基づいて、個人用サイトとソーシャル コンピューティング ポータルのパフォーマンスと容量を計画する方法について説明します。その内容は次のとおりです。
テスト環境の仕様 (ハードウェア、ファーム トポロジ、構成など)
テスト ファームのデータセット
テスト データと推奨事項。推奨事項には、テスト環境を展開するために必要なハードウェア、トポロジ、および構成をどのように決定するかに関する推奨事項と、適切な容量とパフォーマンスの特性に合わせて環境をどのように最適化するかに関する推奨事項が含まれます
要旨
ここでは、個人用サイトとソーシャル コンピューティング ポータルのテストから得られた主な結果について説明します。
環境では、1 台のアプリケーション サーバーと 1 台のデータベース サーバーに対してフロントエンド Web サーバーを 8 台までスケール アップしました (8×1×1)。スループットは始めから最後までほぼ直線的に増加しました。9 台以上のフロントエンド Web サーバーを追加してもスループットは増加しませんでした。これは、この時点でのボトルネックがデータベース サーバーの CPU 使用率であったことが原因です。
コンテンツ データベースとサービス データベースを個別のデータベース サーバーに分離することで、さらにスケール アウトしました (8×1×2)。
8x1x2 トポロジを使用しているときに最大のスループットに到達しました。そのとき、フロントエンド Web サーバーの使用率とアプリケーション サーバーの CPU 使用率がボトルネックでした。このことから、特定のハードウェア、データセット、およびテスト ワークロードを使用した場合の 1 秒あたりの要求数 (RPS) の最大値は、8x1x2 の最大ゾーン RPS (約 1,877 RPS) であると考えられます。
傾向から判断して、フロントエンド Web サーバーとアプリケーション サーバーのボトルネックに対応すれば、正常なファームで同じスループットを得られる可能性があります。フロントエンド Web サーバーのボトルネックは、フロントエンド Web サーバーを追加することで対応できます。アプリケーション サーバーのボトルネックは、アプリケーション サーバーの役割を果たすコンピューターを 2 台使用することで対応できます。ただし、ラボではこれを試していません。
スループットまたはハードウェアの変化は待機時間に影響しません。
セキュリティによるトリミングを有効にした場合、1 台のフロントエンド Web サーバーで、8 ～ 10 RPS の Outlook Social Connector トラフィックに対応できます。つまり、1 台のフロントエンド Web サーバーで、終日 Outlook Social Connector を使用する約 28,000 ～ 36,000 人の従業員に対応できます。したがって、100,000 人の従業員に Outlook Social Connector を導入する場合、Outlook Social Connector トラフィックに対応するために 3 台のフロントエンド Web サーバーが必要になります。これらの値は、社内でのソーシャル タグの使用率に応じて変化する可能性があります。社内で行われるソーシャル タグ アクティビティが、このテスト作業のデータセットで使用したものよりも少ないと考えられる場合は、フロントエンド Web サーバー 1 台あたりのスループットは、8 ～ 10 RPS の範囲を上回る可能性があります。
ファームが正常な状態で維持されている限り、ひとの検索増分クロールはファームのスループットにほとんど影響しません。
この環境の概要
この記事のテスト方法と結果は、ソーシャル コンピューティング ポータルの容量を計画するためのガイダンスを提供します。ソーシャル コンピューティング ポータルは、社内の各ユーザーがユーザー プロファイルの管理、社内の専門家の検索、ニュースフィードを使用した他の従業員との連携、ドキュメントを保管および共有できる個人用サイトの管理を行うことができる SharePoint Server 2010 の展開の 1 つです。ソーシャル コンピューティング機能によって生成されるトラフィックに加えて、個人用サイトでドキュメントのアップロード、共有、表示、および更新を行うユーザーによって大量のコラボレーション トラフィックが生成されます。これらの結果は、個人用サイトとソーシャル機能専用の個別のポータルを設計するときに役立ちます。
シナリオによって要件が異なるので、各自のハードウェアと環境で追加のテストを行うことで、このガイダンスを補完する必要があります。
この記事では、次の方法について説明します。
サポートする必要があるスケール アウトに必要なハードウェアを推定する。この推定では、ユーザー数、ロード、および有効にする機能を考慮する必要があります。
最適な信頼性と効率を得るための物理トポロジと論理トポロジを設計する。この記事では、高可用性と障害復旧は対象外です。
進行中のひとの検索クロールとプロファイルの同期がソーシャル コンピューティング ポータル展開の RPS に与える影響を考慮する。
この記事を読む前に、以下の記事を読んでおく必要があります。
典型的なコラボレーション シナリオに関する容量計画のガイダンスについては、「企業イントラネット共同作業環境の技術的ケース スタディ (SharePoint Server 2010)」を参照してください。
注意
このラボの研究では、ソーシャル コンピューティング ポータル展開でカスタム コードを実行しませんでした。個人用サイトとソーシャル コンピューティング ポータルにインストールされている可能性があるカスタム コードまたはサードパーティ ソリューションの動作については保証できません。
注意
このラボの研究では、NTLM 認証を使用しました。
用語集
次のリストに、この記事で使用する主な用語の定義を示します。
RPS: 1 秒あたりの要求数。RPS は、1 秒間にファームまたはサーバーが受信した要求の数です。これはサーバー ロードおよびファーム ロードの一般的な計測基準です。
要求は、ページ ロードとは異なる点に注意してください。各ページには複数のコンポーネントが含まれ、それらは、ページが読み込まれるときに 1 つまたは複数の要求を作成するからです。従って、1 つのページ ロードでは複数の要求が作成されます。通常、認証チェックと、重要ではないリソースを使用するイベントは、RPS 計測でカウントされません。
グリーン ゾーン: これは、サーバーが以下の一連の要件を維持することができる状態です。
要求の少なくとも 75% でのサーバー側待機時間が 1 秒未満。
すべてのサーバーでの CPU 使用率が 50% 未満。
注意
このラボ環境ではアクティブな検索クロールが実行されていなかったので、データベース サーバーの CPU 使用率は 40% 以下に維持され、検索クロール ロードは 10% に維持されていました。ここでは、検索クロール ロードを 10% CPU に制限するために、運用環境で Microsoft SQL Server リソース ガバナーが使用されているものとします。
- 障害発生率が 0.01% 未満。
レッド ゾーン (最大): これは、サーバーが以下の一連の要件を維持することができる状態です。
HTTP 要求調整機能が有効であるが、503 エラー (サーバー使用中) が返されない。
HTTP 要求の失敗率が 0.1% 未満。
要求の少なくとも 75% でのサーバー側待機時間が 1 秒未満。
データベース サーバーの CPU 使用率が 80% 未満。これは、検索クロール ロードに確保されている 10% の使用率を考慮に入れており、SQL Server リソース ガバナーを使用して制限されます。
AxBxC (グラフの注釈): これは、ファーム内のフロントエンド Web サーバー、アプリケーション サーバー、およびデータベース サーバーの数を表します。たとえば、8x1x2 は、この環境に 8 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、および 2 台のデータベース サーバーが含まれることを意味します。
VSTS ロード: 仮想ユーザーをシミュレートするために Visual Studio Team System (VSTS) によって内部で使用されるスレッドがあります。このテストでは、トポロジに対してさらに多くの RPS を生成するために VSTS ロードを増やしました。
**MDF と LDF:**SQL Server 物理ファイル。詳細については、「ファイルとファイル グループのアーキテクチャ」を参照してください。
概要
ここでは、スケーリング方法、このラボ環境と類似するケース スタディ環境の関係、およびテスト方法について説明します。
スケーリング方法
環境内のコンピューターは特定の順序でスケーリングすることをお勧めします。推奨方法は、ラボ環境をスケーリングするときに使用したのと同じ方法です。この方法を採用することによって、ワークロードにとって最適な構成を見つけることができます。ラボ環境で使用した方法は次のとおりです。
まず、フロントエンド Web サーバーをスケール アウトしました。テスト対象のワークロードで、データベース サーバーがフロントエンド Web サーバーからの要求に対応できなくなるまで、できる限りフロントエンド Web サーバーをスケール アウトしました。
この時点まで、コンテンツ データベースとサービス データベース (プロファイル データベース、ソーシャル データベースなど) は、同じデータベース サーバーに配置していました。データベース サーバーがボトルネックになっていることに気付いた時点で、コンテンツ データベースを別のデータベース サーバーに移動して、データベース サーバーをスケール アウトしました。その後、フロントエンド Web サーバーによって生成されるデータベース サーバーのロードは、フロントエンド Web サーバーをさらにスケール アウトできるレベルまで下がりました。
ラボ環境では、これを上回るスケール アウトはテストしませんでした。ただし、さらにスケーリングする必要がある場合には、次は必然的に 2 台のコンピューターでアプリケーション サーバーの役割を分担することになります。
このテストでは、1 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、および 1 台の SQL Server ベースのコンピューターという最小のファーム構成から開始しました。複数の反復を経て、8 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、および 2 台の SQL Server というファーム構成で終了しました。後の「結果と分析」セクションでは、グリーン ゾーンと最大ゾーンのパフォーマンス特性を各反復間で比較できます。各反復のグリーン ゾーンと最大ゾーンを特定した方法については、「反復の結果」セクションで説明しています。
ラボ環境を運用環境に関連付ける
この記事で示しているラボ環境は、Microsoft の運用環境の小さいスケール モデルです。2 つの環境間には大きな違いがありますが、どちらの環境も個人用サイトとソーシャル コンピューティング環境なので、両方を並べて見ると役に立ちます。その結果、観察されるパターンは似ているはずです。
ラボ環境では、運用環境のデータセットによく似たデータセットを使用します。テストに使用するワークロードは、運用環境のワークロードとほぼ同じで、大きな違いはほとんどありません。最も大きな違いは、ラボ環境は、運用環境に比べて操作を実行する重複しないユーザーの数が少ないことと、操作の対象となるユーザー プロファイルの数が少ないことです。また、ラボでのテストは短い時間で行われます。これらはすべて、アプリケーション サーバーに格納されているユーザー プロファイル キャッシュに対して発生するキャッシュ ヒットの数に影響します。
User Profile Service は、最近使用されたユーザー プロファイルをアプリケーション サーバーにキャッシュします。このキャッシュの既定サイズは 256 MB で、約 500,000 個分のユーザー プロファイルに相当します。テストで使用したユーザー プロファイルの数は 1,500 に限定され、テストを実施した時間は、キャッシュのリサイクル時間よりも短かったため、ほとんどの場合キャッシュ ヒットが発生しました。このため、この記事に示されているスループットの数値は、高い方に位置します。実際の環境では確実にキャッシュ ミスを考慮し、スループットの数値はこれよりも低くなると考える必要があります。
Microsoft の個人用サイトとソーシャル コンピューティング ポータルの運用環境に関するケース スタディの詳細については、「ソーシャル環境の技術的ケース スタディ (SharePoint Server 2010)」を参照してください。
方法とテストの注意事項
この記事では、テスト ラボ環境から得られた結果を示しています。これはラボ環境のため、このワークロードに対して特定のパフォーマンスの性質を示すために特定の要素を制御できました。また、ラボ環境では運用環境の一部の要素を取り除いて、テストのオーバーヘッドを簡素化しました。運用環境では、これらの要素を省くことはお勧めしません。
テストの実行間で変数を 1 つずつ変更して、テストの実行間で結果を簡単に比較できるようにしました。
冗長性はこのテストの目的としては必要なかったので、このラボ環境で使用されたデータベース サーバーはクラスターには含まれていませんでした。
検索クロールはテスト中に実行されませんでしたが、運用環境では実行される可能性があります。このことを考慮して、検索クロールがテストと同じ時間に実行された場合に検索クロールが消費すると考えられるリソースに対応するためにグリーン ゾーンとレッド ゾーン (最大) の定義では、SQL Server の CPU 使用率を低くしました。
仕様
このセクションでは、ラボ環境のハードウェア、ソフトウェア、トポロジ、および構成の詳細について説明します。
ハードウェア
次の表は、このテストで使用されたコンピューターのハードウェア仕様を示しています。テストの複数の反復中にサーバー ファームに追加されたフロントエンド Web サーバーもこれらの仕様と一緒にまとめられています。
| フロントエンド Web サーバー | アプリケーション サーバー | データベース サーバー | |
|---|---|---|---|
プロセッサ |
2px4c@2.33 GHz |
2px4c@2.33 GHz |
4px4c@3.10 GHz |
RAM |
8 GB |
8 GB |
32 GB |
ネットワーク アダプターの数 |
2 |
2 |
1 |
ネットワーク アダプターの速度 |
1 ギガビット |
1 ギガビット |
1 ギガビット |
ロード バランサーの種類 |
F5 - ハードウェア ロード バランサー |
該当なし |
該当なし |
ULS ログ レベル |
中 |
中 |
該当なし |
ソフトウェア
次の表は、このテストで使用されたコンピューターのソフトウェア仕様を示しています。テストの複数の反復中にサーバー ファームに追加されたフロントエンド Web サーバーもこれらの仕様と一緒にまとめられています。
| フロントエンド Web サーバー | アプリケーション サーバー | データベース サーバー | |
|---|---|---|---|
オペレーティング システム |
Windows Server 2008 R2 x64 |
Windows Server 2008 R2 x64 |
Windows Server 2008 x64 |
ソフトウェアのバージョン |
Microsoft SharePoint 4763.1000 (RTM)、Office Web Applications 4763.1000 (RTM) |
Microsoft SharePoint 4763.1000 (RTM)、WAC 4763.1000 (RTM) |
SQL Server 2008 R2 CTP3 |
ロード バランサーの種類 |
F5 - ハードウェア ロード バランサー |
該当なし |
該当なし |
ULS ログ レベル |
中 |
中 |
該当なし |
ウイルス対策設定 |
無効 |
無効 |
無効 |
実行するサービス |
SharePoint Foundation 受信電子メール SharePoint Foundation Web アプリケーション SharePoint Foundation Workflow Timer Service |
サーバーの全体管理 Excel Calculation Services Managed Metadata Web Service SharePoint Foundation 受信電子メール SharePoint Foundation Web アプリケーション SharePoint Foundation Workflow Timer Service PowerPoint Service User Profile Service User Profile Synchronization Service Word Viewing Service |
トポロジ
次の図は、このラボ環境のトポロジを示しています。
.gif "この環境のファーム トポロジの図")
データセットとディスク ジオメトリ
テスト ファームには次のデータを格納しました。
166.5 GB の個人用サイトコンテンツ、10 個のコンテンツ データベースに均等に配分
27.7 GB のプロファイル データベース コンテンツ
3.7 GB のソーシャル データベース コンテンツ (ソーシャル タグ、メモ、および評価の GUID)
0.14 GB の Managed Metadata データベース コンテンツ (ソーシャル タグのテキストと対応する GUID)
次の表では、データセットについて詳しく説明します。
ユーザー プロファイルの数 |
～ 150K |
ユーザー 1 人あたりの平均メンバーシップ数 |
74 |
ユーザー 1 人あたりの直属の部下の平均数 |
6 |
ユーザー 1 人あたりの仕事仲間の平均数 |
28 |
プロファイル プロパティの合計数 |
101 |
複数値プロパティの数 |
21 |
対象ユーザーの数 |
130 |
個人用サイトの数 |
～ 10K |
ブログ サイトの数 |
～ 600 |
アクティビティ フィードでのイベントの合計数 |
798K* |
ソーシャル タグと評価の数 |
504 万** |
* del.icio.us によるソーシャル タグの調査は、アクティブなユーザーは 1 か月に 4.2 個のタグを作成することを示唆しています。ここでのタグとは、メタデータを URL に関連付けるあらゆるアクティビティのことを指しています。これには、キーワード タグ、評価、およびメモが含まれます。つまり、アクティブなユーザーは、4.2 タグ/30 日 = 0.14 タグ/日を作成します。ソーシャル ポータルのユーザーの 3 分の 1 がタグ付けを行うと仮定すると、タグ付けイベントは 1 日あたり 150K/3 × 0.14 個になります。アクティビティ フィード テーブルでは、アクティビティが 14 日間保管されます。したがって、アクティビティ フィード テーブルに格納されるタグ付けイベントの合計数は、150K/3 × 0.14 × 14 です。タグ付けイベントに加えて、アクティブなユーザーが 1 日あたりもう 1 つ別のイベント (プロファイル プロパティの更新や進捗の更新) を生成すると仮定した場合、アクティビティ フィード テーブルに 150K/3 × 1 × 14 個のイベントが追加されます。したがって、アクティビティ フィード テーブルのイベントの合計数は、150K/3 × 1.14 × 14 = 798K になります。これらのイベントのうち、98K はセキュリティによるトリミングが発生する可能性があるタグ付けアクティビティです。残りのイベントは、進捗の更新とプロファイル プロパティの変更にランダムに配分されます。
** 全ユーザーの 3 分の 1 がアクティブなユーザーで、各ユーザーが 1 か月あたり 4.2 個のタグを作成すると仮定しています。このタグは、キーワード タグ、メモ、または評価のことです。ファームが 2 年間存続していると仮定すると、タグの合計数は 150K/3 × 4.2 × 12 × 2 = 5.04 MB になります。
次の表では、ディスク ジオメトリについて詳しく説明します。
| データベース | コンテンツ DB 1、2、3、4 | コンテンツ DB 5、6 | コンテンツ DB 7、8 | コンテンツ DB 9、10 | プロファイル | ソーシャル | メタデータ |
|---|---|---|---|---|---|---|---|
データベース サイズ |
61.4 GB |
39 GB |
32.3 GB |
33.7 GB |
27.7 GB |
3.7 GB |
0.14 GB |
RAID 構成 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
MDF 用のスピンドルの数 |
1 |
1 |
1 |
1 |
6 |
1 |
1 |
LDF 用のスピンドルの数 |
すべてのデータベースで 1 つの物理スピンドルを共有 |
テスト ミックス
重要事項:
テストでシミュレートしているのは、プライム タイムの典型的なソーシャル コンピューティング ポータルの使用量だけです。昼/夜の周期で見られるユーザーが生成するトラフィックの周期的な変化は考慮していません。プロファイルの同期、ひとの検索クロールなど、相当な量のリソースを必要とするタイマー ジョブは、その影響を特定するために同じテスト ワークロードを使用して個別にテストしました。
テストでは、ニュースフィード、ソーシャル タグ、ユーザー プロファイルの読み取りなど、ソーシャル関連の操作に重点を置いています。典型的なコラボレーション トラフィックは少量です。このトラフィックには重点を置いていません。これらの結果は、個人用サイトとソーシャル機能専用の個別のポータルを設計するときに役立つと考えています。
テスト ミックスには、検索コンテンツ クロールからのトラフィックは含まれていません。ただし、検索クロールの CPU 使用率を 10% と見込んで、グリーン ゾーンの定義を標準の 50% の SQL Server CPU 使用率ではなく 40% に修正することでこれをテストに組み込みました。同様に、80% の SQL Server CPU を最大 RPS の基準として使用しました。
次の表に示すテスト ミックスの他に、Outlook Social Connector トラフィック分として各フロントエンド Web サーバーに 8 RPS を追加しました。セキュリティによるトリミングを有効にしました。Secure Token Service は、仕事仲間のアクティビティを取得するときに 1 台のフロントエンド Web サーバーで約 8 RPS の Outlook Social Connector トラフィックに近付いたときに顕著な負荷の兆候を示しました。これは、テストするときにラボで使用したデータセット、テスト ワークロード、ハードウェアが関係しています。環境によってはまったく異なる動作が確認される可能性があります。Secure Token Service にこれ以上負荷がかからないようにするために、各反復でのフロントエンド Web サーバーの台数に応じて Outlook Social Connector トラフィックを追加することにしました。したがって、1x1x1 の場合は 8 RPS の Outlook Social Connector トラフィックを追加し、2x1x1 の場合は 16 RPS の Outlook Social Connector トラフィックを追加しました。
次の表にテスト ミックス全体を示します。
| テスト | 読み取り/書き込み | ミックスの割合 |
|---|---|---|
仕事仲間を追加する |
書き込み |
2.11 |
URL の評価を作成する、メモを記入する、URL にタグを付ける |
書き込み |
3.22 |
操作ドキュメントのリストを作成する |
読み取り/書き込み |
2.36 |
発行されたリンクを取得して、PublishedLinksService.asmx へのクライアント呼び出しをシミュレートする |
読み取り |
6.92 |
リストから RSS フィードを取得する |
読み取り |
3.72 |
個人用サイトでドキュメント ライブラリとリストにあるすべてのアイテムを表示する |
読み取り |
1.07 |
ブログの投稿を表示する |
読み取り |
0.04 |
さまざまな個人用サイト ページ (個人用コンテンツ、仕事仲間、ニュースフィード、個人用プロファイル、他のユーザーのプロファイル、組織のブラウザー、メンバーシップ、タグ、およびメモ) を表示する |
読み取り |
3.87 |
共有 OneNote ファイルに合わせて同期する |
読み取り |
10.0 |
個人用プロファイル ページまたは状態メッセージを編集する。画像を更新する |
書き込み |
2.31 |
Office Web Apps: ファイルを開いてスクロールする (PowerPoint、Word、および Excel) |
読み取り |
0.13 |
Outlook との同期のリストを作成する |
読み取り |
48.16 |
ドキュメントをアップロードする |
書き込み |
0.09 |
コンテンツ データベースからページ、ドキュメント ライブラリ、およびフォルダーを読み込む |
読み取り |
15.93 |
ドキュメントを共同編集する |
読み取り/書き込み |
0.17 |
次の表では、フロントエンド Web サーバーごとに 8 RPS 生成する追加の Outlook Social Connector シナリオのテスト ミックスについて説明します。
自分の仕事仲間を自動的に同期する |
読み取り |
4% |
自分の仕事仲間のニュースフィードを自動的に同期する |
読み取り |
96% |
結果と分析
すべての反復の比較
前述のとおり、このテストでは、1 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、および 1 台の SQL Server ベースのコンピューターという最小のファーム構成から開始しました。複数の反復を経て、最終的に 8 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、および 2 台の SQL Server コンピューターというファーム構成で終了しました。各反復でステップ ロード テストを実行し、グリーン ゾーンと最大ゾーンを特定しました。次の表では、各反復でのグリーン ゾーンと最大ゾーンのパフォーマンス特性を比較できます。
比較と分析を行えるように以下の表とグラフに概要を示します。
グリーン ゾーンの結果
次の表は、各トポロジでのグリーン ゾーンのパフォーマンス特性をまとめたものです。
| トポロジ | 1x1x1 | 2x1x1 | 3x1x1 | 5x1x1 | 8x1x1 | 8x1x2 |
|---|---|---|---|---|---|---|
グリーン ゾーン RPS |
137.25 |
278.08 |
440.72 |
683.07 |
793.67 |
873.4 |
グリーン ゾーンの 75 パーセンタイル待機時間 |
0.12 |
0.16 |
0.14 |
0.16 |
0.31 |
0.32 |
グリーン ゾーンのフロントエンド Web サーバー CPU |
47.84 |
46.88 |
48.68 |
46.13 |
31.79 |
36.90 |
グリーン ゾーンのアプリケーション サーバー CPU |
9.45 |
18.88 |
26.91 |
35.58 |
48.73 |
47.20 |
グリーン ゾーンの SQL Server CPU |
5.45 |
10.61 |
16.46 |
24.73 |
30.03 |
32.40 (17.9 がコンテンツ DB、14.5 がサービス DB) |
次のグラフは、グリーン ゾーンの結果に関して RPS の上に各トポロジが示した CPU 使用率をプロットしたもので、CPU 使用率の変化を示しています。
.gif "グリーンゾーンでの RPS に関する CPU 使用率を示す図")
前の図を参照:
コンピューターをトポロジに追加するにつれて、RPS は最後まで増加しました。
ご覧のとおり、フロントエンド Web サーバーの CPU は 5x1x1 までトポロジをグリーン ゾーンの限界に導く強力な要因でした。8x1x1 で、フロントエンド Web サーバーがグリーン ゾーンの限界に到達する前にアプリケーション サーバーの CPU がグリーン ゾーンの限界に到達しました。
テスト全体を通して、SQL Server の CPU はきわめて正常な範囲にとどまり続けました。
最大ゾーンの結果
次の表は、各トポロジの最大ゾーンの結果をまとめたものです。
| 1x1x1 | 2x1x1 | 3x1x1 | 5x1x1 | 8x1x1 | 8x1x2 | |
|---|---|---|---|---|---|---|
最大ゾーン RPS |
203.28 |
450.75 |
615.00 |
971.13 |
1655 |
1877 |
最大ゾーン待機時間 |
0.22 |
0.23 |
0.22 |
0.22 |
0.31 |
0.32 |
最大ゾーンのフロントエンド Web サーバー CPU |
75.13 |
78.17 |
70.00 |
67.02 |
67 |
71.6 |
最大ゾーンのアプリケーション サーバー CPU |
12.97 |
27.07 |
28.40 |
48.28 |
67.1 |
73.4 |
最大ゾーンの SQL Server CPU |
7.64 |
16.06 |
21.00 |
38.38 |
79.5 |
74.9 (45.9 がコンテンツ DB、29 がサービス DB) |
次のグラフは、最大ゾーンの結果に関して RPS の上に各トポロジが示した CPU 使用率をプロットしたもので、CPU 使用率の変化を示しています。
.gif "マックスゾーンでの RPS に関する CPU 使用率を示す図")
前の図を参照:
コンピューターをトポロジに追加するにつれて、RPS は最後まで増加しました。
ご覧のとおり、5x1x1 までフロントエンド Web サーバーの CPU がボトルネックでした。8x1x1 で、SQL Server の CPU がボトルネックになりました。
最初は、アプリケーション サーバーの CPU 使用率のほうが SQL Server の CPU 使用率よりも高い値を示していました。ただし、SQL Server の CPU 使用率の上昇率は、アプリケーション サーバーの CPU 使用率の上昇率を上回っています。スループット レベルが高くなると、SQL Server の CPU 使用率はアプリケーション サーバーの CPU 使用率を追い越し、ボトルネックになりました。
グリーン ゾーンと最大ゾーン
次のグラフでは、各トポロジでのグリーン ゾーンと最大ゾーンのスループットと待機時間を比較しています。
.gif "各トポロジでの RPS を示す図")
.gif "各トポロジの待機時間を示す図")
前の図を参照:
待機時間は、スループットまたはトポロジが変化してもあまり変わりません。このテストでは、待機時間はすべて 0.5 秒未満でしたので、十分許容できる値です。
スループットはほぼ直線的に増加しています。
ディスク I/O
次の表とグラフは、各トポロジの各データベースで観察されたディスク I/O を示しています。ディスク I/O がボトルネックになることはありませんでした。なお、傾向から判断して、後半のトポロジについてはデータを記録しませんでした。
| 1x1x1 最大ゾーン | 2x1x1 最大ゾーン | 3x1x1 最大ゾーン | 5x1x1 最大ゾーン | |
|---|---|---|---|---|
読み取り数/秒 (コンテンツ DB) |
21.33 |
20.80 |
24.24 |
22.42 |
読み取り数/秒 (プロファイル DB) |
14.97 |
17.20 |
19.82 |
13.50 |
読み取り数/秒 (ソーシャル DB) |
1.81 |
1.83 |
2.10 |
2.01 |
書き込み数/秒 (コンテンツ DB) |
50.12 |
76.24 |
80.02 |
99.16 |
書き込み数/秒 (プロファイル DB) |
9.01 |
24.31 |
23.35 |
38.29 |
書き込み数/秒 (ソーシャル DB) |
4.12 |
9.47 |
10.63 |
19.45 |
.gif "各トポロジでの 1 秒あたりの I/O 数を示す図")
ひとの検索クロールの影響
このテストでは、構成およびエンド ユーザーの待機時間によって提供されるスループットに対するひとの検索クロールの影響を測定しようと考えました。このテストでは、8x1x1 構成が示す結果を基準として使用し、ひとの検索増分クロールを開始しました。増分クロールでは、53 分間で 49,375 アイテムのインデックスを作成しました。
次の表では、ひとの検索増分クロールを実行した場合と実行していない場合について、8x1x1 構成が示すパフォーマンス特性を比較しています。
| 基準の 8x1x1 グリーン ゾーンの結果 | ひとの検索クロールを実行した場合の 8x1x1 グリーン ゾーンの結果 | |
|---|---|---|
スループット (RPS) |
1024.00 |
1026.00 |
フロントエンド Web サーバー CPU (%) |
39.84 |
41.6 |
アプリケーション サーバー CPU (%) |
41.40 |
43.1 |
コンテンツ/サービス SQL Server CPU (%) |
36.63 |
39.5 |
クロール サーバー CPU (%) |
0.52 |
34.6 |
検索用の SQL Server CPU (%) |
3.62 |
14.8 |
前の表を参照:
RPS はほとんど変わっていません。8x1x1 グリーン ゾーンではリソースのボトルネックが発生しなかったので、RPS が影響を受ける理由はありません。
フロントエンド Web サーバーとコンテンツ/サービス SQL Server の CPU 使用率は少しだけ向上しました。
クロール サーバーと検索用の SQL Server の CPU 使用率は、それぞれ 0.5% から 34.6% と 3.6% から 14.8% に増加しました。
分析
アプリケーション サーバーのスケール
アプリケーション サーバーは、どの構成でもボトルネックではありませんでした。さらに、任意の 1 つの構成で各 VSTS ロードに対するアプリケーション サーバーの CPU 使用率を見ると、上昇してから横ばいになっていることがわかります。これの典型的な例が、次の表に示す 8x1x1 構成に見られます。
| VSTS ロード | 416 | 616 | 816 | 1016 | 1216 | 1416 | 1616 |
|---|---|---|---|---|---|---|---|
アプリケーション サーバーの CPU 使用率 (%) |
37.6 |
49.4 |
57.9 |
61.9 |
67.1 |
65.3 |
63.10 |
これは予想されていた結果です。ソーシャル ポータルの場合、ほとんどの操作で SharePoint Server User Profile Service とやり取りする必要があります。ほとんどの操作では、User Profile Service を作成するときに準備したプロファイル データベースからユーザーのプロファイルを取得する必要があります。
頻繁な SQL Server とのラウンド トリップを回避するために、User Profile Service 用のアプリケーション サーバーではユーザー プロファイルのキャッシュが保存されます。テスト環境をウォームアップしている初期の段階では、このキャッシュは空で、アプリケーション サーバーはフロントエンド Web サーバーから受信した要求に対し、SQL Server からユーザー プロファイルを絶えず取得して応答します。このプロファイルはキャッシュされるので、フロントエンド Web サーバーからの要求はすべて、SQL Server とのラウンド トリップなしでアプリケーション サーバーが応答できるようになります。アプリケーション サーバーは、キャッシュでプロファイルを探して要求に応答します。
テストで使用したユーザー プロファイルの数は限られているので、アプリケーション サーバーによってすべてのユーザー プロファイルがキャッシュされるのを確認しました。それに応じて、使用率は上昇を示しました。すべてのプロファイルがキャッシュされると、キャッシュ検索という安定した動作になりました。したがって、アプリケーション サーバーの CPU 使用率は低下し安定しました。
Outlook Social Connector トラフィックとセキュリティによるトリミング
Outlook Social Connector は Office 2010 に付属のアドインで、SharePoint 仕事仲間のアクティビティを Outlook で確認できます。このアドインは、2007 Microsoft Office system と Microsoft Office 2003 用にも用意されており、無料でダウンロードできます。
Outlook Social Connector は SharePoint Server を 1 時間に 1 回チェックし、特定のユーザーの仕事仲間としてリストに登録されているユーザーのアクティビティを取得します。Outlook Social Connector は毎回そのアクティビティをキャッシュします。以降の仕事仲間のアクティビティ チェックでは、最後に SharePoint Server をチェックしてから新しいアクティビティが発生していないかどうかだけを確認します。このため、非常に予測がつきやすいトラフィック パターンをたどります。Outlook Social Connector と SharePoint Server を 100,000 人分展開した場合、すべてのユーザーが終日このアドインを使用すると仮定すると、Outlook Social Connector は 1 時間に 100,000 個の要求を生成します。これは 27.77 RPS に相当します。
仕事仲間のアクティビティを表示することによって、情報漏えいにつながる可能性があります。たとえば、仕事仲間がタグを付けた URL に、他のユーザーがアクセスできない機密情報が含まれている場合があります。この場合、ユーザーは Outlook Social Connector でコンテンツを表示したときに、そのコンテンツに機密部分があることに気付く可能性があります。このような情報漏えいを防ぐために、SharePoint Server はすべてのアクティビティをフィルター処理し、アクティビティ フィードでユーザーがアクセスできる URL だけを表示します。このフィルター処理をセキュリティによるトリミングと呼んでいます。既定ではセキュリティによるトリミングは有効になっています。ただし、これは SharePoint Server 管理者によって無効にできます。
すべてのアクティビティにセキュリティによるトリミングが必要なわけではありません。SharePoint Server 2010 でサポートされる 16 種類のアクティビティのうち、セキュリティによるトリミングが必要なのは 4 個のアクティビティ (タグ付け、メモ掲示板のコメント、評価、および配布リスト (DL) のメンバーシップの変更) だけです。また、Outlook Social Connector は最後に同期してから発生したアクティビティの差分だけを確認するので、セキュリティによるトリミングが必要な 1 ユーザーあたりのアクティビティ数は適切な範囲に収まると考えられます。
セキュリティによるトリミングを必要とする Outlook Social Connector からの要求はすべて、Search Service アプリケーション サーバーに対する認証済みの Windows Communication Foundation (WCF) 呼び出しになります。この呼び出しで使用する認証トークンを取得するために、最初に Secure Token Service に対して WCF 呼び出しが行われます。
Outlook Social Connector RPS がフロントエンド Web サーバー 1 台につき 8 RPS を上回った場合、Secure Token Service に負荷がかかることがわかりました。Secure Token Service への負荷は、ユーザーの合計数とユーザーの仕事仲間のアクティビティで発生するソーシャル タグの総量の影響を受けるので、ユーザーによっては発生しない場合があります。このテストで作成したデータセットと使用したユーザーでは、セキュリティによるトリミングを必要とするアクティビティが十分生成されたので、この現象が確認されたと判断しました。このため、使用するフロントエンド Web サーバーの台数に応じて Outlook Social Connector トラフィックを増加しました。1x1x1 構成の場合、8 RPS の Outlook Social Connector トラフィックを生成しました。2x1x1 構成の場合、16 RPS の Outlook Social Connector トラフィックを生成しました。
つまり、テストに使用したデータセット、テスト ミックス、およびハードウェアの場合、約 8 × 60 × 60、1 時間あたり 28,800 個の要求に対応できました。Outlook Social Connector のしくみでは、セキュリティによるトリミングが有効な 1 台のフロントエンド Web サーバーで Outlook Social Connector を使用する 28,800 人の従業員に対応できました。同様に、セキュリティによるトリミングが有効な 3 台のフロントエンド Web サーバーでは、Outlook Social Connector を使用する 28,800 × 3、つまり 86,400 人の従業員に対応できました。
これは、Outlook Social Connector トラフィックに対応するために必要なハードウェアを見積もるときに役に立つと考えられます。ただし、このテストで確認した結果は、このテストに使用したデータセット、テスト ミックス、およびハードウェアに固有のものです。また、Windows PowerShell 2.0 を使用してセキュリティによるトリミングを無効にするか、Outlook Social Connector が SharePoint Server と同期する頻度を変更できます。この 2 つの選択肢は両方とも、ハードウェア要件に大きく影響します。
反復の結果
以下の結果は、前の「概要」で説明したスケーリング方法に基づいて並べられています。
1x1x1 トポロジ
ここでは、1 台の Web サーバー、1 台のアプリケーション サーバー、および 1 台のデータベース サーバーを使用したときのテスト結果について説明します。
結果のまとめ
この記事で前に示したテスト ミックスの他に、このファームには、ユーザーによるフィード イベントを求める Outlook Social Connector の 8 RPS トラフィックがありました。
1 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、および 1 台の SQL Server コンピューターで構成されたファームで、フロントエンド Web サーバーが明らかにボトルネックでした。次の表に示すように、このドキュメントの前半で説明したトランザクション ミックスを使用してファームが 238 RPS を受けたときにフロントエンド Web サーバー CPU は、約 90% の使用率に到達しました。
この構成では、137.25 のグリーン ゾーン RPS を示しました。そのときの 75% の待機時間は 0.12 秒、フロントエンド Web サーバー CPU は約 47.8% の使用率でした。これは、このファームでは、約 137.25 の RPS を正常に実現できることを意味します。このファームが示した最大ゾーン RPS は 203.2 で、そのときの待機時間は 0.22 秒、フロントエンド Web サーバー CPU は約 85% でした。
フロントエンド Web サーバーがボトルネックだったので、次の反復ではもう 1 台のフロントエンド Web サーバーをファームに追加しました。
パフォーマンス カウンターとグラフ
次の表は、1x1x1 ファームのテスト中に取得した各種のパフォーマンス カウンターを VSTS ロードのステップごとに示しています。
| VSTS ロード | 52 | 77 | 102 | 127 | 152 | 177 |
|---|---|---|---|---|---|---|
RPS |
99.8 |
147 |
188 |
218 |
238 |
243 |
フロントエンド Web サーバー CPU |
33.9 |
50 |
71.8 |
81.1 |
90.8 |
89 |
アプリケーション サーバー CPU |
7.92 |
11.7 |
13.5 |
14.1 |
13.9 |
13.3 |
SQL Server CPU |
4.7 |
6.48 |
7.99 |
8.21 |
8.41 |
8.88 |
75 パーセンタイル [秒] |
0.13 |
0.16 |
0.17 |
0.25 |
0.3 |
0.45 |
95 パーセンタイル [秒] |
0.29 |
0.47 |
0.41 |
0.55 |
0.55 |
0.77 |
.gif "1x1x1 トポロジでの RPS と待機時間を示す図")
.gif "1x1x1 トポロジでの RPS と CPU 使用率を示す図")
2x1x1 トポロジ
ここでは、2 台の Web サーバー、1 台のアプリケーション サーバー、および 1 台のデータベース サーバーを使用したときのテスト結果について説明します。
結果のまとめ
この記事で前に示したテスト ミックスの他に、このファームには、ユーザーによるフィード イベントを求める Outlook Social Connector の 16 RPS トラフィックがありました。
2 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、および 1 台の SQL Server コンピューターで構成されたファームで、フロントエンド Web サーバーがボトルネックでした。次のデータに示すように、このドキュメントの前半で説明したトランザクション ミックスを使用してファームが 520 RPS を受けたときにフロントエンド Web サーバー CPU は、約 89% の使用率に到達しました。
この構成では、278 のグリーン ゾーン RPS を示しました。そのときの 75% の待機時間は 0.16 秒、フロントエンド Web サーバー CPU は約 47% の使用率でした。これは、このテストで使用したテスト ミックスとハードウェアを使用すると、このファームでは約 278 の RPS を正常に実現できることを意味します。このファームが示した最大ゾーン RPS は 450 で、そのときの待機時間は 0.23 秒、フロントエンド Web サーバー CPU は約 78% でした。
この反復ではフロントエンド Web サーバー CPU がボトルネックだったので、次の反復ではもう 1 台フロントエンド Web サーバーを追加してこのボトルネックを軽減しました。
パフォーマンス カウンターとグラフ
次の表とグラフは、2x1x1 ファームのテスト中に取得した各種のパフォーマンス カウンターを VSTS ロードのステップごとに示しています。
| VSTS ロード | 104 | 154 | 204 | 254 | 304 | 354 |
|---|---|---|---|---|---|---|
RPS |
190 |
278 |
390 |
455 |
500 |
520 |
フロントエンド Web サーバー CPU |
36 |
50.9 |
71.9 |
86.9 |
87.1 |
89.5 |
アプリケーション サーバー CPU |
16 |
24.9 |
28.3 |
26.5 |
26.5 |
24.9 |
SQL Server CPU |
8.06 |
10.6 |
14.2 |
16.4 |
17.9 |
18.9 |
75 パーセンタイル [秒] |
0.16 |
0.22 |
0.22 |
0.33 |
0.42 |
0.53 |
95 パーセンタイル [秒] |
0.42 |
0.64 |
0.51 |
0.69 |
0.73 |
0.89 |
.gif "2x1x1 トポロジでの RPS と待機時間を示す図")
.gif "2x1x1 トポロジでの RPS と CPU 使用率を示す図")
3x1x1 トポロジ
ここでは、3 台の Web サーバー、1 台のアプリケーション サーバー、および 1 台のデータベース サーバーを使用したときのテスト結果について説明します。
結果のまとめ
この記事で前に示したテスト ミックスの他に、このファームには、ユーザーによるフィード イベントを求める Outlook Social Connector の 24 RPS トラフィックがありました。
3 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、および 1 台の SQL Server コンピューターで構成されたファームで、フロントエンド Web サーバーがボトルネックでした。次のデータに示すように、このドキュメントの前半で説明したトランザクション ミックスを使用してファームが 629 RPS を受けたときにフロントエンド Web サーバー CPU は、約 76% の使用率に到達しました。
この構成では、440 のグリーン ゾーン RPS を示しました。そのときの 75% の待機時間は 0.14 秒、フロントエンド Web サーバー CPU は約 48% の使用率でした。これは、このテストで使用したテスト ミックスとハードウェアを使用すると、このファームでは約 440 の RPS を実現できることを意味します。このファームが示した最大ゾーン RPS は 615 で、そのときの待機時間は 0.22 秒、フロントエンド Web サーバー CPU は約 70% でした。
この反復ではフロントエンド Web サーバー CPU がボトルネックだったので、フロントエンド Web サーバーを追加することにしました。これまでにフロントエンド Web サーバーを 1 台ずつ追加したときに確認された反復間の差分を考慮して、2 台のフロントエンド Web サーバーを追加することを決定しました。2 台追加することで、アプリケーション サーバーまたは SQL Server コンピューターがボトルネックになることを確認したいと考えました。
パフォーマンス カウンターとグラフ
次の表とグラフは、3x1x1 ファームのテスト中に取得した各種のパフォーマンス カウンターを VSTS ロードのステップごとに示しています。
| VSTS ロード | 156 | 231 | 306 | 381 | 456 | 531 |
|---|---|---|---|---|---|---|
RPS |
264 |
393 |
532 |
624 |
634 |
629 |
フロントエンド Web サーバー CPU |
30.5 |
46.3 |
62.55 |
72.95 |
75.4 |
76 |
アプリケーション サーバー CPU |
22.7 |
35.6 |
34.2 |
32.5 |
32.5 |
29.4 |
SQL Server CPU |
10.4 |
14.8 |
20.8 |
22.5 |
22.8 |
22.4 |
75 パーセンタイル [秒] |
0.17 |
0.26 |
0.27 |
0.28 |
0.31 |
0.40 |
95 パーセンタイル [秒] |
0.63 |
1.08 |
0.76 |
0.68 |
0.88 |
0.98 |
.gif "3x1x1 トポロジでの RPS と待機時間を示す図")
.gif "3x1x1 トポロジでの RPS と CPU 使用率を示す図")
5x1x1 トポロジ
ここでは、5 台の Web サーバー、1 台のアプリケーション サーバー、および 1 台のデータベース サーバーを使用したときのテスト結果について説明します。
結果のまとめ
この記事で前に示したテスト ミックスの他に、このファームには、ユーザーによるフィード イベントを求める Outlook Social Connector の 40 RPS トラフィックがありました。
5 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、および 1 台の SQL Server コンピューターで構成されたファームで、SQL Server CPU とアプリケーション サーバー CPU の使用率が大きく上昇するのを確認しましたが、依然としてフロントエンド Web サーバー CPU がボトルネックでした。次のデータに示すように、このドキュメントの前半で説明したトランザクション ミックスを使用してファームが 1315 RPS を受けたときにフロントエンド Web サーバー CPU は、約 88% の使用率に到達しました。
この構成では、683 のグリーン ゾーン RPS を示しました。そのときの 75% の待機時間は 0.16 秒、フロントエンド Web サーバー CPU は約 46% の使用率でした。これは、このテストで使用したテスト ミックスとハードウェアを使用すると、このファームでは約 683 の RPS を正常に実現できることを意味します。このファームが示した最大ゾーン RPS は 971 で、そのときの待機時間は 0.22 秒、フロントエンド Web サーバー CPU は約 68% でした。
傾向から判断して、3 台のフロントエンド Web サーバーを追加して 8x1x1 構成をテストすることを決定しました。この構成でアプリケーション サーバーまたは SQL Server がボトルネックになることを確認したいと考えました。
パフォーマンス カウンターとグラフ
次の表とグラフは、5x1x1 ファームのテスト中に取得した各種のパフォーマンス カウンターを VSTS ロードのステップごとに示しています。VSTS ロードまたは構成の変化は待機時間に大きな影響を与えないことを確認したので、待機時間の記録を中止しました。
| VSTS ロード | 260 | 385 | 510 | 635 | 760 | 885 |
|---|---|---|---|---|---|---|
RPS |
359 |
560 |
901 |
1188 |
1281 |
1315 |
フロントエンド Web サーバー CPU |
20.5 |
34 |
56.2 |
77.5 |
86.1 |
88 |
アプリケーション サーバー CPU |
40.2 |
50.6 |
66.9 |
71.3 |
66.3 |
58.7 |
SQL Server CPU |
13.9 |
20.3 |
34.9 |
53.6 |
58.4 |
64 |
.gif "5x1x1 トポロジでの RPS と CPU 使用率を示す図")
8x1x1 トポロジ
ここでは、8 台の Web サーバー、1 台のアプリケーション サーバー、および 1 台のデータベース サーバーを使用したときのテスト結果について説明します。
結果のまとめ
この記事で前に示したテスト ミックスの他に、このファームには、ユーザーによるフィード イベントを求める Outlook Social Connector の 64 RPS トラフィックがありました。
8 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、および 1 台の SQL Server コンピューターで構成されたファームで、SQL Server CPU が最終的にボトルネックになりました。次のデータに示すように、このドキュメントの前半で説明したトランザクション ミックスを使用してファームが 1664 RPS を受けたときに SQL Server CPU は、約 80% の使用率に到達しました。
この構成では、793 のグリーン ゾーン RPS を示しました。そのときの 75% の待機時間は 0.31 秒、SQL Server CPU は約 30% の使用率でした。ただし、アプリケーション サーバーの CPU 使用率は約 48% でした。これは、このテストで使用したテスト ミックスとハードウェアを使用すると、このファームでは約 793 の RPS を正常に実現できることを意味します。このファームが示した最大ゾーン RPS は 1655 で、そのときの待機時間は 0.31 秒、SQL Server CPU は約 80% でした。
この反復では SQL Server CPU がボトルネックだったので、次の反復ではコンテンツ データベースとサービス データベースを SQL Server の 2 つのインスタンスに分けてこのボトルネックを軽減しました。
パフォーマンス カウンターとグラフ
次の表とグラフは、8x1x1 ファームのテスト中に取得した各種のパフォーマンス カウンターを VSTS ロードのステップごとに示しています。
| VSTS ロード | 416 | 616 | 816 | 1016 | 1216 | 1416 | 1616 |
|---|---|---|---|---|---|---|---|
RPS |
664 |
1101 |
1359 |
1530 |
1655 |
1664 |
1617.00 |
フロントエンド Web サーバー CPU |
26.7 |
44.4 |
54.7 |
61.5 |
67 |
65.9 |
65.10 |
アプリケーション サーバー CPU |
37.6 |
49.4 |
57.9 |
61.9 |
67.1 |
65.3 |
63.10 |
SQL Server CPU |
23.2 |
42 |
57.9 |
69.5 |
79.5 |
80.8 |
77.30 |
.gif "8x1x1 トポロジでの RPS と CPU 使用率を示す図")
8x1x2 トポロジ
ここでは、8 台の Web サーバー、1 台のアプリケーション サーバー、および 2 台のデータベース サーバーを使用したときのテスト結果について説明します。
結果のまとめ
この記事で前に示したテスト ミックスの他に、このファームには、ユーザーによるフィード イベントを求める Outlook Social Connector の 64 RPS トラフィックがありました。
8 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、および 2 台の SQL Server コンピューターで構成されたファームで、構成をその極限まで利用できました。フロントエンド Web サーバーとアプリケーション サーバーの両方がボトルネックでしたが、合算した SQL Server の使用率も 70 を上回っていました。ファームは最大ロードで 1817 の RPS を示しました。
これはこのテストで試した最後の反復です。ただし、さらにスケーリングする必要がある場合には、次は確実に 2 台のコンピューターを使用してアプリケーション サーバーの役割を遂行することになります。これにより、フロントエンド Web サーバーの台数を増やすことができるので、各フロントエンド Web サーバーのロードを軽減できます。
パフォーマンス カウンターとグラフ
次の表とグラフは、8x1x2 ファームのテスト中に取得した各種のパフォーマンス カウンターを VSTS ロードのステップごとに示しています。
| VSTS ロード | 466 | 666 | 866 | 1066 | 1266 | 1416 |
|---|---|---|---|---|---|---|
RPS |
466.00 |
873.40 |
1431.00 |
1703.00 |
1766.00 |
1817.00 |
フロントエンド Web サーバー CPU |
19.90 |
36.90 |
57.60 |
68.00 |
71.40 |
71.60 |
アプリケーション サーバー CPU |
29.80 |
47.20 |
63.50 |
71.40 |
71.90 |
73.40 |
SQL Server CPU の合計 |
19.61 |
32.40 |
55.20 |
63.60 |
68.50 |
74.90 |
コンテンツ SQL Server CPU |
9.93 |
17.90 |
31.90 |
40.10 |
42.30 |
45.90 |
サービス SQL Server CPU |
9.68 |
14.50 |
23.30 |
23.50 |
26.20 |
29.00 |
.gif "8x1x2 トポロジでの RPS と CPU 使用率を示す図")
執筆者について
Gaurav Doshi は Microsoft のプログラム マネージャーです。
Wenyu Cai は、Microsoft のテストでのソフトウェア エンジニアです。