office web apps のパフォーマンスとキャパシティ...
TRANSCRIPT
Office Web Apps のパフォーマンスとキャパシティ要件を検討する
このドキュメントは現状有姿で提供され、このドキュメント (URL などのインターネット Web サイトにある参照先を含む) に記載さ
れている情報および見解は、将来予告なしに変更することがあります。その使用責任はお客様ご自身にあります。
このドキュメントに記載されている例の一部は、例示のみを目的としており、架空のものです。実在する事物とは一切関係ありませ
ん。
このドキュメントは、あらゆるマイクロソフト製品に対する何らかの知的財産権をお客様に付与するものではありません。このドキュメン
トは、内部的な参照目的にのみコピーおよび使用することができます。
© 2010 Microsoft Corporation. All rights reserved.
目次
テスト ファームの特性 ........................................................................................ 3
負荷 ....................................................................................................... 3
ハードウェア設定とトポロジ ............................................................................... 8
データ セット ............................................................................................. 10
テスト結果 .............................................................................................. 10
推奨事項 .................................................................................................. 15
パフォーマンスとスケーラビリティのトラブルシューティング ................................................... 18
パフォーマンス監視 ...................................................................................... 18
Web サーバー .......................................................................................... 18
Office Web Apps のパフォーマンスとキャパシティ要件を検討する
この記事の内容 :
テスト ファームの特性
テスト結果
推奨事項
トラブルシューティング
このパフォーマンスと処理能力の計画ドキュメントは、Microsoft® SharePoint® Server 2010 を実行するトポロジ内で
Office Web App を使用することによるフットプリントのガイダンスを提供します。
各 Office Web App のパフォーマンス特性は少し異なるため、展開を計画する際に考慮する処理能力特性も少し異なります。
このドキュメントは、アプリケーションごとに異なるパフォーマンスと処理能力の特性について説明します。
SharePoint Server 2010 の処理能力計画とその実行の一般的な情報については、「パフォーマンスと処理能力の管理 」を
参照してください。
テスト ファームの特性
このセクションでは、パフォーマンスの収集時に製品にかかる負荷、テスト中に使用されるハードウェア、およびハードウェアの展開方
法のトポロジについて説明します。また、テスト中に使用されるデータ セットについて簡単に説明します。これら 3 つの要素を組み
合わせて、Office Web App のパフォーマンスの概要を提供します。
負荷
Word Web App と PowerPoint® Web App の場合、ドキュメント表示とドキュメント編集は、サーバーの展開によってサービ
スの提供方法が異なり、パフォーマンス特性も異なるため、この 2 つのモードを個別に考慮することが重要です。OneNote®
Web App では、この違いがはるかに小さいため、処理能力を考慮する際に区別する必要はありません。
テストする負荷の一覧を次に示します。
Word Web App でのドキュメントの表示と PowerPoint Web App でのプレゼンテーションの表示
Word Web App でのドキュメントの編集と PowerPoint Web App でのプレゼンテーションの編集
PowerPoint Web App での PowerPoint ブロードキャストの表示 (出席者側)
OneNote Web App ノートブックの表示/編集
これらの負荷のテストは、以下の変動要素が変化した場合にさまざまなファーム構成がどのように挙動するかについて予測するため
の参考資料として行われました。
使用される Web App の組み合わせと頻度
以前にレンダリングしたドキュメント/プレゼンテーションを表示するときのキャッシュ ヒット率の効果
ドキュメント/プレゼンテーションのタイプと予測される要求の組み合わせ
この記事に記載されている処理能力やパフォーマンスの数値は、現実の環境での数値とは異なることに注意してください。記載さ
れている数値は、適切な規模の環境を設計するための出発点を提供するためのものです。最初のシステム設計を完成したら、そ
の構成をテストして、システムが環境内の諸要素をサポートしているかどうかを判断してください。
テストの定義
このセクションでは、テスト シナリオを定義し、各シナリオで使用されたテスト プロセスの概要を提供します。テスト結果や固有のパ
ラメーターなどの詳細情報は、この記事で後述する各テスト結果のセクションに示します。
Word Web App の表示
下のテストはそれぞれ、ドキュメントの出力形式が PNG の場合と Silverlight の場合の 2 回実行されました。各テストがどの程
度使用されたかという正確な組み合わせは、この後の「テスト ミックス」のセクションにあります。
テスト名 テストの説明
完全なドキュメントの読み取り 1. ドキュメントを開きます。
2. 次のページにスクロールし、各ページで一時停止します。
3. 最後のページまでスクロールします。
4. ドキュメントを閉じます。
複数検索と読み取り 1. ドキュメントを開きます。
2. ランダムなページにスクロールします。
3. 検索コマンドを実行し、結果に移動します。
4. ランダムなページにスクロールします。
5. 2 回目の検索コマンドを実行し、結果に移動します。
6. ドキュメントを閉じます。
単一検索と読み取り 1. ドキュメントを開きます。
2. 検索コマンドを実行し、結果に移動します。
3. ドキュメントの最後まで 1 ページずつスクロールします。
4. ドキュメントを閉じます。
間違ったドキュメントの読み取り 1. ドキュメントを開きます。
2. 2 ページにスクロールします。
3. ドキュメントを閉じます。
印刷 1. ドキュメントを PDF 形式で出力します。
Word Web App の編集
テスト名 テストの説明
完全な編集 1. Word エディターを読み込みます。
2. ドキュメントを読み込みます。
3. ドキュメントをスペル チェックしてから一時停止します。
4. 入力をシミュレートします。間に待機時間を置きながら、さまざまな保存やスペル要求を実行します。
5. ドキュメントを閉じます。
PowerPoint Web App の表示
テスト名 テストの説明
完全な表示 1. PowerPoint ビューアを開きます。
2. プレゼンテーションを読み込みます。
3. スライドを表示し、一時停止します。
4. 次のスライドに移動し、一時停止します。
5. これをプレゼンテーションの最後まで繰り返します。
PowerPoint Web App の編集
テスト名 テストの説明
完全な編集 1. PowerPoint ビューアを開きます。
2. プレゼンテーションを読み込みます。
3. スライドを表示し、75% の確率でテキスト オブジェクトを編集し、一時停止します。
4. 次のスライドを表示し、75% の確率でテキスト オブジェクトを編集し、一時停止します。
5. これをプレゼンテーションの最後まで繰り返します。
6. プレゼンテーションを閉じて保存します。
PowerPoint Web App のブロードキャスト
テスト名 テストの説明
完全なブロー
ドキャスト
1. プレゼンテーションから PowerPoint ブロードキャストを作成します。
2. 5 人の出席者の PowerPoint ビューアで各ブロードキャストを表示します。
3. スライドの表示を開始し、一時停止します。
4. 次のスライドに移動し、一時停止します。
5. これをプレゼンテーションの最後まで繰り返します。
6. ブロードキャストを終了します。
OneNote Web App
テスト名 テストの説明
コラボレーション シナリオ #1 同期間隔が 5 秒になるように設定します。
1. ノートブックを読み込みます。
2. 新しいページをクリックし、一時停止します。
3. 1 分間編集してからスペル チェックを行います。
4. もう 1 分間編集してからスペル チェックを行います。
5. 画像を挿入します。
6. ページに大きなデータを貼り付け、スペル チェックを行います。
7. 貼り付けたデータに変更を加えます。
8. 一部のコンテンツを削除します。
コラボレーション シナリオ #2 同期間隔が 5 秒になるように設定します。
1. ノートブックを読み込みます。
2. ノートブックをランダムな間隔で繰り返し保存します。
単一ユーザー シナリオ #1 同期間隔が 30 秒になるように設定します。
1. ノートブックを読み込みます。
2. 新しいページをクリックし、一時停止します。
3. 編集を行って時間ベースのバージョンを作成します。
4. 2 分間編集してから、スペル チェックを行います。
5. 画像を挿入します。
6. ページに大きなデータを貼り付けます。
7. 一部のコンテンツを削除します。
単一ユーザー シナリオ #2 同期間隔が 30 秒になるように設定します。
1. ノートブックを読み込みます。
2. ノートブックをランダムな間隔で繰り返し保存します。
テスト ミックス
Word Web App の表示
ソリューション名 出力形式 ミックス内の割合 (%)
完全なドキュメントの読み取り PNG 9.75
SL 3.25
複数検索と読み取り PNG 40.5
SL 13.5
単一検索と読み取り PNG 17.25
SL 5.75
間違ったドキュメントの読み取り PNG 4.5
SL 1.5
印刷 PDF 4
Word Web App の編集
ソリューション名 ミックス内の割合 (%)
完全な編集 100
OneNote Web App
ソリューション名 ミックス内の割合 (%)
コラボレーション シナリオ #1 5
コラボレーション シナリオ #2 5
単一ユーザー シナリオ #1 45
単一ユーザー シナリオ #2 45
PowerPoint Web App の表示
ソリューション名 ミックス内の割合 (%)
完全な表示 100
PowerPoint Web App の編集
ソリューション名 ミックス内の割合 (%)
完全な編集 100
PowerPoint Web App のブロードキャスト
ソリューション名 ミックス内の割合 (%)
完全なブロードキャスト 100
ハードウェア設定とトポロジ
ラボ ハードウェア
高度なテスト結果の詳細を提供するために、複数のファーム構成を使用してテストを行いました。ファーム構成は、1 ～ 6 台の
Web サーバーと、Microsoft® SQL Server® 2008 データベース ソフトウェアを実行する 1 台のデータベース サーバー コンピュ
ーターです。テストは、数台のクライアント コンピューターで実行されました。すべての Web サーバー コンピューターとデータベース サ
ーバーは 64 ビットで、クライアント コンピューターは 32 ビットです。テスト中に SharePoint Server 固有の読み込みはなく、操
作されていたコンピューターは、Web App 要求を処理するコンピューターだけでした。
このドキュメントは、Web フロントエンド コンピューターとアプリケーション サーバーの効果、およびそれらの特性が Web App の処
理能力にどのように関連するかを中心に説明します。
テストで使用したハードウェアの詳細を次の表に示します。
コンピューター名 WFE1 ～ 8 アプリケーション サー
バー
SPSQL
役割 WFE アプリケーション SQL Server
プロセッサ 2 プロセッサ、4 コ
ア、各 2.33 GHz
2 プロセッサ、4 コ
ア、各 2.33 GHz
4 プロセッサ、4 コ
ア、各 3.2 GHz
RAM 8 GB 8 GB 16 GB
オペレーティング システム Windows Windows Windows
Server® 2008
SP2 x64
Server 2008
SP2 x64
Server 2008
SP2 x64
ストレージとそのジオメトリ
(SQL Server のディスク構
成を含む)
6 + 75 + 590
GB
6 + 75 + 590
GB
6 + 75 + 460
GB
NIC の数 2 2 2
NIC 速度 1 GB 1 GB 1 GB
認証 基本 NTLM NTLM
ソフトウェア バージョン 4753.1000 4753.1000 SQL Server
2008
SQL Server のインスタンス
数
1
ロード バランサーの種類 NLB
ULS ログ レベル ミディアム ミディアム ミディアム
トポロジ
異なるアプリケーションには、異なるトポロジが必要です。1 つの要求を満たすために複数のコンピューターの役割が必要になるケー
スでは、フロントエンド Web サーバーとアプリケーション サーバーの割合を変えて、さまざまなトポロジをテストしました。それらのケー
スでは、以下の表の “ボトルネック” 列に、どの層で最初に余裕がなくなったか、それはフロントエンド Web サーバーとアプリケーショ
ン サーバーのどちらであったかが記載されています。この情報は、フロントエンド Web サーバーにかかる負荷がどの程度重いかがわ
かっている場合に便利です。つまり、フロントエンド Web サーバーに既に大きな負荷がある場合は、最初にアプリケーション サーバ
ーに余裕がなくなるようなトポロジで Web App を展開すると、さらにフロントエンド Web サーバーにかかる負荷を最小限に抑え
ることができます。
キャッシュ ヒットがない Word Web App の表示、キャッシュ ヒットがない PowerPoint Web App の表示、PowerPoint
Web App の編集、および PowerPoint ブロードキャストの場合は、ドキュメントをエンド ユーザーに表示する前にアプリケーショ
ン サーバーがそのドキュメントをレンダリングする必要があります。次の図は、1 台のフロントエンド Web サーバーと 2 台のアプリケ
ーション サーバーから成る 1 x 2 トポロジです。
キャッシュされたドキュメントを提供する Word Web App の表示またはキャッシュされたドキュメントを提供する PowerPoint
Web App の表示の場合は、1 台のフロントエンド Web サーバーのみが必要です。同様に、Word Web App の編集と
OneNote には、フロントエンド Web サーバーのみが必要です。このような負荷を処理できる 1 台のフロントエンド Web サーバ
ーの基本トポロジを次に示します (ただし、さらにアプリケーション サーバーが展開され、キャッシュされていない Word Web App
要求の処理に加わることに注意してください。キャッシュされている要求を処理するにはどのコンピューターが必要かを示すために、こ
こにはアプリケーション サーバーを描き加えていません)。
Server Switch
SQL StoreWeb Front End
データ セット
この Web App テストで使用したデータ セットはすべて、Microsoft Office 2007 ファイル形式のドキュメントでした。
Word の場合、使用したドキュメントは、10 ～ 216 KB、1 ～ 30 ページ、0 ～ 7000 ワードとさまざまなサイズでした。書式
設定がほとんど入っていないドキュメントもあれば、さまざまなスタイルと書式設定が使用された複雑なドキュメントもあります。
OneNote の場合、すべてのテストが新しい空のワークブックから始まり、テストが進むにつれてサイズと複雑さが増しました。
PowerPoint の場合、使用したプレゼンテーションは、サイズが 250 ～ 1,275 KB で、平均 15 枚のスライドが含まれていまし
た。また、プレゼンテーションには、さまざまな種類のコンテンツが入っていました。
テスト結果
次の表に、SharePoint Server 2010 内の Office Web App の結果を示します。各テスト グループに対して特定の変動要
素のみを変化させて、ファームのパフォーマンスに対する逐次的な影響を示しています。
Word および OneNote Web App についてこの記事で報告されているテストには、思考時間 (連続して行う操作の間の自然
な遅延) が含まれています。これは、ユーザーがサーバーに送信した直前の要求の結果を検討し、次に行う要求を決定するまでに
発生する短い停止時間をシミュレートします。この思考時間は、実際の環境に見られる事象を単に近似的に表すものとして加え
られています。
SharePoint Server 2010 内の Office Web App のボトルネックの詳細については、この記事の後半にある「典型的なボト
ルネックとその原因」のセクションを参照してください。
Word Web App の表示 (キャッシュ ヒットなし)
次の詳細は、Web フロントエンドとアプリケーション サーバー バックエンドのトポロジを変更した場合の結果を示しています (1 x 2
は 1 台のフロントエンドと 2 台のアプリケーション サーバー。すべてを 1 つの SQL Server インスタンスでサポート)。ユーザー数
は、そのトポロジでサポートされる、Word Web App を使用してアクティブにドキュメントを表示できるユーザー数の予測値です。
トポロジ RPS 平均応答時
間
ボトルネック 平均 WFE
CPU
平均 App
Server
CPU
SQL Server
CPU
サポートされ
るアクティブ
ユーザー数
1x1 25 0.2 秒
アプリケーショ
ン サーバー 8% 48% 2% 860
1x2
33 0.16 秒
フロントエンド
Web サーバ
ーでの HTTP
スロットル
8.5% 38% 2.5% 1040
2x2 48 0.16 秒
アプリケーショ
ン サーバー 8% 49% 3.5% 1600
2x3
64 0.15 秒
フロントエンド
Web サーバ
ーでの HTTP
スロットル
10% 42% 5% 2100
3x3 65 0.12 秒
アプリケーショ
ン サーバー 7% 45% 5.5% 2200
Word Web App の表示 (すべてキャッシュ ヒット)
上と同様ですが、ここでは、要求されているドキュメントがそれぞれ既にレンダリングされており、Web App キャッシュにある場合のパ
フォーマンスをシミュレートします。ドキュメントを再レンダリングする必要がない場合は、RPS とスループットが向上するほか、Web フ
ロントエンドが要求を直接処理できるため、アプリケーション サーバー コンピューターが必要ありません。どのケースでも HTTP スロッ
トルが発生するため、「ボトルネック」列が削除されていることに注意してください。
トポロジ RPS 平均応答時間 平均 WFE CPU SQL Server CPU サポートされるアク
ティブ ユーザー数
1 WFE 24 0.15 秒 11% 2% 990
2 WFE 33 0.25 秒 7.5% 2.5% 1500
3 WFE 50 0.25 秒 7% 3.5% 2250
4 WFE 80 0.35 秒 10% 4.5% 3100
5 WFE 108 0.05 秒 10% 7.5% 4400
Word Web App の編集
ドキュメントを編集する場合は、Web フロントエンドのみが必要です。編集中は処理が重くなる可能性があるため、特定のコンピュ
ーター セットにかけることができる負荷量には範囲があります。この範囲の両端は、「レッド ゾーン(短時間なら耐えられるが避けるべ
き状態)」と「グリーン ゾーン(維持可能な状態)」で表されます。Web App を展開する場合は、次のグリーン ゾーンの表で説明す
るパフォーマンス特性を目標にすることをお勧めします。フロントエンド Web サーバーが Office Web App セッション以外にはほと
んどサービスを提供しないことがわかっている場合は、これより「レッド ゾーン」に近いパフォーマンス特性を目標にすることにも妥当性
があります。
グリーン ゾーン(維持可能な状態)の RPS
トポロジ RPS 平均応答時間 平均 WFE CPU SQL Server CPU サポートされるアク
ティブ ユーザー数
1 WFE 285 0.03 秒 50% 3% 240
2 WFE 292 0.04 秒 50% 8% 540
3 WFE 330 0.06 秒 50% 12% 720
レッド ゾーン(短時間なら耐えられるが避けるべき状態)の RPS
トポロジ RPS 平均応答時間 平均 WFE CPU SQL Server CPU サポートされるアク
ティブ ユーザー数
1 WFE 286 0.04 秒 75% 5% 420
2 WFE 333 0.08 秒 74% 12% 780
3 WFE 600 0.14 秒 75% 19% 1200
OneNote Web App
ドキュメントを編集する場合は、Web フロントエンドのみが必要です。上と同様に、推奨されるグリーン ゾーンのパフォーマンス特性
と、レッド ゾーンの表には上限値の両方を示します。
グリーン ゾーン(維持可能な状態)の RPS
トポロジ RPS 平均応答時間 平均 WFE CPU SQL Server
CPU
サポートされるアクティブ ユ
ーザー数
1 WFE 97 0.1 秒 50% 9% 1260
2 WFE 199 0.15 秒 50% 19% 2520
3 WFE 275 0.5 秒 50% 30% 3720
レッド ゾーン(短時間なら耐えられるが避けるべき状態)の RPS
トポロジ RPS 平均応答時間 平均 WFE CPU SQL Server
CPU
サポートされるアクティブ ユ
ーザー数
1 WFE 135 0.4 秒 75% 12% 1700
2 WFE 250 1.0 秒 75% 28% 3780
3 WFE 340 1.0 秒 61% 36% 5160
PowerPoint Web App の表示 (キャッシュなし) Web App で PowerPoint ファイルを表示する場合は、ファイルを Web ビューアの形式にレンダリングするためにアプリケーション
サーバーが使用されます。次に、レンダリング結果は Web App キャッシュに置かれます。
次の詳細は、Web フロントエンドとアプリケーション サーバー バックエンドのトポロジを変更した場合の結果を示しています (1 x 2
は 1 台のフロントエンドと 2 台のアプリケーション サーバー。すべてを 1 つの SQL Server インスタンスでサポート)。ユーザー数は、
そのトポロジでサポートされる、PowerPoint Web App を使用してアクティブにドキュメントを表示できるユーザー数の予測値です。
トポロジ RPS 平均応答
時間
ボトルネック 平均 WFE
CPU
平均 App
Server
CPU
SQL
Server
CPU
サポートさ
れるアクティ
ブ ユーザー
数
1x1 90 0.04 秒
アプリケーション サー
バー 7.3% 68% 2.1% 900
1x2
140 0.045 秒
フロントエンド Web
サーバーでの HTTP
スロットル
10% 58% 3% 1500
2x2 158 0.047 秒
アプリケーション サー
バー 5.4% 62% 3.6% 1500
2x3 200 0.042 秒
アプリケーション サー
バー 7.45% 55% 4.7% 2100
3x3
192 0.05 秒
フロントエンド Web
サーバーでの HTTP
スロットル
4% 66% 5% 2000
PowerPoint Web App の表示 (キャッシュあり) 上と同様ですが、ここでは、要求されているドキュメントがそれぞれ既にレンダリングされており、Web App キャッシュにある場合のパ
フォーマンスをシミュレートします。ドキュメントを再レンダリングする必要がない場合は、RPS とスループットが向上するほか、Web フ
ロントエンドが要求を直接処理できるため、アプリケーション サーバー コンピューターが必要ありません。どのケースでも HTTP スロッ
トルが発生するため、「ボトルネック」列が削除されていることに注意してください。
トポロジ RPS
平均応答時間 平均 WFE CPU SQL Server
CPU
サポートされるアクティブ
ユーザー数
1 WFE 350 0.01 秒 21.1% 3% 700
2 WFE 200 0.01 秒 7% 2% 1400
3 WFE 111 0.01 秒 12% 2% 2100
4 WFE 180 0.01 秒 8% 3% 2857
5 WFE 225 0.01 秒 5% 3.5% 3571
PowerPoint Web App の編集 Web App で PowerPoint ファイルを編集する場合は、Web フロントエンドとアプリケーション サーバーの両方が必要です。ただ
し、負荷の大部分はアプリケーション サーバーにかかり、このメモリが制限になります。
トポロジ RPS 平均応答
時間
平均 WFE
CPU
平均 App
Server CPU
App erver
メモリ使用
率
SQL
Server
CPU
サポートされる
アクティブ
ユーザー数
1x1 48 1.18 2.8% 40% 87.5% 0.6% 600
1x2 125 1.19 4.76% 37% 87.5% 1.3% 1200
1x3 142 1.28 6.58% 34.6% 87.5% 1.3% 1800
PowerPoint ブロードキャスト (既定の “MaxPendingReceives=1”) Web App で PowerPoint ブロードキャストを表示する場合は、Web フロントエンドとアプリケーション サーバーの両方が必要で
す。各出席者は、ブロードキャストの状態を調べるために毎秒 1 回サーバーを ping します。したがって、RPS は、サポートされるア
クティブ ユーザーの概数を示します。
既定では、Web フロントエンドは、アプリケーション サーバーの “MaxPendingReceives” 設定がボトルネックになります。既定の
“MaxPendingReceives” 設定 1 と、これを調整した設定 10 の両方のデータを示します。CPU の使用率が問題になる場合
は、Web フロントエンドの PowerPoint ブロードキャストの使用率を調整することもできます。PowerPoint ブロードキャスト向け
にサーバー ファームをパフォーマンス調整する方法については、「ブロードキャスト スライドショーのパフォーマンスを構成する」を参照し
てください。
トポロジ RPS
平均応答時間 平均 WFE
CPU
平均 App Server
CPU
SQL Server
CPU
サポートされる
アクティブ
ユーザー数
1x1 295 0.36 20.7% 37.3% 3.7% 300
1x2 590 0.32 30.5% 23.5% 1.7% 600
2x2 671 0.83 18.1% 38.45% 2% 700
2x3 797 0.47 26.5% 26.5% 2% 800
3x3 842 0.87 19% 34% 3% 850
PowerPoint ブロードキャスト (“MaxPendingReceives=10”) web.config ファイルで “MaxPendingReceives” 設定を 10 にすると (この設定を変更する方法については、上のリンクのガイ
ドを参照)、特定のトポロジでスループットとサポートされるユーザー数が大幅に増加します。また、スループットが増加することのトレ
ードオフとして、フロントエンド Web サーバーの CPU に非常に大きな負荷がかかります。
トポロジ RPS 平均応答時間 平均 WFE
CPU
平均 App Server
CPU
SQL Server
CPU
サポートされる
アクティブ
ユーザー数
1x1 1070
0.16 95% 37.5% 1%
1000
1x2 1024
0.17 95% 12% 1%
1000
2x2 1934
0.16 48% 39.5% 1.5%
2000
2x3 1823
0.15 35% 20% 1.6%
2000
3x3 2779
0.12 41.5% 33% 2.2%
2800
推奨事項
このセクションでは、パフォーマンスと処理能力の一般的な推奨事項について説明します。これらの推奨事項を使用して、作成した
開始トポロジの処理能力とパフォーマンスの特性を特定し、開始トポロジをスケールアウトするかスケールアップするかを決定します。
ハードウェアの推奨事項
フロントエンド Web サーバーとアプリケーション サーバーの両方の最小システム要件と推奨システム要件の詳細については、「ハー
ドウェア要件およびソフトウェア要件 (SharePoint Server 2010)」を参照してください。
最適な展開の決定は、予想されるユーザー数、予想される使用率の大きさ、および使用率のタイプによって大きく異なります。独自
の展開のための出発点として、以下のガイドラインを考慮してください。
アプリケーション サーバーとフロントエンド Web サーバー
プロセッサ 2 クアッドコア 2.33 GHz
RAM 16 GB
オペレーティング システム
Windows Server 2008、64 ビット
SharePoint ドライブのサイズ
3 x 146 GB 15K SAS (3 RAID 1 ディスク) ディスク 1: オペレーティング システム ディスク 2: Swap および BLOB キャッシュ ディスク 3: ログおよび一時ディレクトリ
NIC 数 2
NIC 速度 1 GBt
認証 NTLM
ロード バランサーの種類
ハードウェア負荷分散
1 日のユニーク ユーザー数の平均
平均同時ユーザー数 推奨トポロジ
100 10 1 台のフロントエンド Web サーバ
ー、1 台のアプリケーション サーバ
ー
1000 30 2 台のフロントエンド Web サーバ
ー、2 台のアプリケーション サーバ
ー
10000 300 4 台のフロントエンド Web サーバ
ー、3 台のアプリケーション サーバ
ー
PowerPoint ブロードキャスト機能の使用率が非常に高い場合は、別個のサーバー ファームの使用をお勧めします (「ブロードキャ
スト スライドショーのパフォーマンスを構成する」を参照)。
部門展開の具体例とその結果については、「SharePoint 2010 Capacity Planning Case Study: Departmental
Collaboration (SharePoint 2010 処理能力計画のケース スタディ: 部門コラボレーション)」(英語) を参照してください。
トポロジのスケールアップとスケールアウト
出発点となるトポロジの処理能力とパフォーマンスを向上させるには、次の 2 つのいずれかを実行できます。既存のサーバー コンピ
ューターの処理能力を向上させるスケールアップか、トポロジにサーバーを追加するスケールアウトです。このセクションでは、Office
Web App の処理能力を向上させるためにスケールアップとスケールアウトのどちらかを選択する際の考慮事項について説明します。
9 個以上の CPU コアが有効になると、アプリケーション サーバーの効率が大幅に低下します。グローバル ロックを使用す
ると、追加されたコアが効率よく使用されなくなります。この制限に達した場合は、スケールアウトが最も効果的です。
Word Web App の表示が多いユース ケースの場合は、アプリケーション サーバーの CPU が制限になります。処理能
力を向上させるには、コアの追加 (上述の制限内) またはコンピューターの追加が最善の方法です。
Word Web App の編集が多いユース ケースの場合および OneNote Web App の編集または表示が多いユース
ケースの場合は、フロントエンド Web サーバーの CPU が制限になります。スケールアップするには、フロントエンド Web
サーバーに CPU の処理能力を追加します。CPU の処理能力が十分な場合でも、編集の使用率が高いと、やがてフロ
ントエンド Web サーバーのメモリが制限になります。この場合は、スケールアウトすると、最高のパフォーマンスが得られま
す。
PowerPoint Web App の表示が多いユース ケースの場合は、アプリケーション サーバーは CPU が制限になり、フロ
ントエンド Web サーバーはメモリが制限になります。
PowerPoint Web App の編集が多いユース ケースの場合は、アプリケーション サーバーのメモリが制限になります。
PowerPoint ブロードキャストが多いユース ケースの場合は、フロントエンド Web サーバーの CPU が制限になります。
一般に、Web App は、スケールアップするよりスケールアウトする方が堅牢でフェールセーフな環境になるように設計されています。
少数の超大型コンピューターへの展開もよく機能しますが、予想される負荷を処理する必要に応じて、複数のアプリケーション サー
バーと Web フロントエンドでスケールアウトされた展開トポロジの使用をお勧めします。
スケールアウトする場合、アプリケーション サーバーとフロントエンド Web サーバーの最適な比率は、事前にレンダリングされてキャッ
シュされているドキュメントに対する要求の数に依存します。ただし、フロントエンド Web サーバー 1 台対アプリケーション サーバー
4 台の比率を超えることはありません。これは、すべてのドキュメント要求が新しいレンダリングになるとして、当社のラボで決定された
最適な比率です。また、スケールアウトする場合は、クライアントとフロントエンドの間でアフィニティを有効にすることをお勧めします。こ
れにより、特に PowerPoint Web App で最適なパフォーマンスが得られます。
典型的なボトルネックとその原因
パフォーマンス テストの中で、典型的な「ボトルネック」がいくつか明らかになりました。ボトルネックは、ファームの構成要素の 1 つがそ
の処理能力に達した状態です。ボトルネックは、ファームのスループットに停滞または減少をもたらします。
いくつかの典型的なボトルネック、その原因、および考えられる解決策を次の表に示します。
パフォーマンスとスケーラビリティのトラブルシューティング
ボトルネック 原因 解決策
アプリケーション
サーバーの
CPU 使用率
アプリケーション サーバーの負荷が要求によって
過剰になると、CPU の平均使用率は 100%
に近づきます。これにより、アプリケーション サー
バーが要求に迅速に応答できなくなり、クライア
ント コンピューターでタイムアウトが発生したり、
エラー メッセージが表示される可能性がありま
す。
アプリケーション サーバーは最大 8 コアまで使用できます
が、それを超える場合は、追加のアプリケーション サーバ
ーを有効にする必要があります。使用率のピーク時にもド
キュメントがほとんどキューに入らないようにすることをお勧
めします。ベスト プラクティスとしては、CPU 使用率のピ
ークを 70 パーセント未満に収めます。
Web サーバー
の CPU 使用
率
Web サーバーの負荷がユーザー要求によって
過剰になると、CPU の平均使用率は 100%
に近づきます。これにより、Web サーバーが要
求に迅速に応答できなくなり、クライアント コン
ピューターでタイムアウトが発生したり、エラー メ
ッセージが表示される可能性があります。
この問題を解決するには、次の 2 つの方法のどちらかを
使用します。ファームに Web サーバーを追加して、ユー
ザー負荷を分散させます。または、高速のプロセッサを追
加して、Web サーバーまたはサーバーをスケールアップし
ます。
パフォーマンス監視
システムをスケールアップまたはスケールアウトする必要があるかどうかを判断するには、パフォーマンス カウンターを使用してシステムの
状態を監視します。以下の表に示された情報を使用して、監視するパフォーマンス カウンターとパフォーマンス カウンターを適用する
プロセスを決定してください。
Web サーバー
次の表に、ファームの Web サーバーを監視するためのパフォーマンス カウンターとプロセスを示します。
パフォーマンス カウンター 適用先
オブジェクト
メモ
プロセッサ時間 合計 このスレッドが命令を実行するためにプロセッサを使用した経過時間の割合を
示します。
メモリ使用率 アプリケーション
プール
アプリケーション プールによるシステム メモリの平均使用率を示します。監視す
るアプリケーション プールを正しく指定する必要があります。
基本的なガイドラインは、特定の Web アプリケーションのピーク時のメモリ使
用率を把握し、その数に 10 を加えた値を関連するアプリケーション プールに
割り当てることです。
キュー内の変換要求数 アプリケーション
サーバー
アプリケーション サーバーが要求を処理できるようになるまで、キューに入れら
れているレンダリング要求の数を示します。
これは常に 0 になる必要があります。常にキュー内に要求があることは、アプリ
ケーション サーバーが要求の負荷に追いついていないことを示し、ユーザーへの
応答が遅延していることを意味します。
これに対処するには、アプリケーション サーバーを追加するか、Web App 表
示用ワーカー プロセスの最大数を増やすことを検討します。これにより、各アプ
リケーション サーバーで処理できる要求が増えますが、アプリケーション サーバ
ーの CPU 使用率が増大します。Web App 表示用ワーカー プロセスの最
大数は、アプリケーション サーバーにある CPU コアの数まで増やすことができ
ます (最大 8 つ)。ただし、コアを追加してもスループットが上がるとは限りませ
ん。
変換要求のフロントエン
ド キャッシュ ミス数
フロントエンド
Web サーバー
Web フロントエンドのキャッシュによって処理されない表示要求の数を示しま
す。
これは比較的小さい値になるはずです。常にキャッシュ ミスがあると、SQL
Server により多くの要求が送られます。これは、フロントエンド アフィニティを
実装するか、フロントエンド キャッシュのサイズを増やすことで改善できることが
あります。既定では、このキャッシュは 75 MB ですが、Web フロントエンドの
メモリに余裕がある場合は、キャッシュ サイズを 2 GB にすることをお勧めしま
す。
変換要求の平均ダウン
ロード時間および編集
の平均ダウンロード時間
アプリケーション
サーバーおよび
SQL Server ス
トア
ドキュメントが Web App によってレンダリングされる前に、SQL Server スト
アからアプリケーション サーバーにドキュメントをダウンロードするためにかかる時
間を示します。
これは比較的小さい値になるはずです。ダウンロード時間が長いと、ユーザー
はアクセスしようとしているドキュメントを表示できなくなります。これは、アプリケ
ーション サーバーまたは SQL Server ストアの可用性の問題によって発生す
ることがあります。
OneNote エディター
ページ読み込みおよび
Word エディター
ページ読み込み
フロントエンド
Web サーバー
Word および OneNote 編集要求を処理するフロントエンド Web サーバ
ーの場合、これは、ページの読み込みに必要な時間を示します。大きなピーク
が続く場合は、負荷を処理するためのフロントエンド Web サーバーが十分で
はないことを示します。
BroadcastGetData
率
フロントエンド
Web サーバー
PowerPoint ブロードキャストを表示するユーザーの概数を示します。
BroadcastGetData 要求率が高い場合は、多数のユーザーが
PowerPoint ブロードキャストを表示していることを示します。つまり、
PowerPoint ブロードキャスト ビューアが、望ましいフロントエンド CPU 時間
より多くの時間を使用している可能性があります。合計 CPU 使用率が高い
場合は、これがサーバー パフォーマンス全体に影響することがあります。
