Microsoft SharePoint Server 2010 ベースの部門別ポータルのキャパシティプランニングとサイズ変更 このドキュメントは現状有姿で提供され このドキュメント (URL などのインターネット Web サイトにある参照先を含む ) に記載されている情報および見解は 将来予告なし

Transcription

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

2 Microsoft SharePoint Server 2010 ベースの部 門別ポータルのキャパシティプランニングとサイズ変更 Gaurav Doshi Raj Dhrolia Wayne Roseberry Microsoft Corporation 2010 年 2 月 適用 : Office SharePoint Server 2010 概要 : このホワイトペーパーは SharePoint Server 2010 ベースの部門別ポータルのパフォーマンスとキャパシティプランニングのガイダンスを提供します ハードウェア ファームトポロジ 構成などのテスト環境の仕様 テストファームのデータセット 類似した環境を展開するために必要なハードウェア トポロジ 構成を決定する方法と 適切な処理能力とパフォーマンス特性を得るために環境を最適化する方法に関するテストデータと推奨事項

3 目次 はじめに... 4 シナリオ... 4 仮定と前提条件... 4 テストのセットアップ... 6 ハードウェア... 6 ソフトウェア... 6 トポロジと構成... 7 データセットとディスクジオメトリ... 7 トランザクションミックス... 8 結果と分析 テストの手法 反復の結果 (1 X 1 1 X 1 X 1 2 X 1 X 1 3 X 1 X 1) X 1 ファーム構成 X 1 X 1 ファーム構成 X 1 X 1 ファーム構成 X 1 X 1 ファーム構成 比較 検索増分クロールを使用したテスト 結果と推奨事項のまとめ... 21

4 はじめに シナリオ このドキュメントは 典型的な部門別ポータルのキャパシティプランニングについて そのガイダンスを提供するためのテストの手法と結果の概要を示します 部門別ポータルは 主にチームで共同作業と何らかのコンテンツ公開を行う 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 ( パフォーマンスと処理能力の技術ケーススタディ ) ページ ( 英語 ) にある Microsoft SharePoint Server 2010 Departmental Collaboration Environment (Microsoft SharePoint Server 2010 部門コラボレーション環境 ) ドキュメント ( 英語 ) 仮定と前提条件 このテストでは ディスク I/O を制限要素と見なしません 利用できるスピンドルの数は無限であることを前提とします テストは 典型的な部門別ポータルのピーク時の使用状況のみをモデリングしています 昼夜のサイクルで見られるようなトラフィックの周期的な変化は考慮していません したがって 一般には夜に実行するようにスケジュールされるタイマージョブも トランザクションミックスには含まれていません この場合は 部門別ポータル展開で実行されるカスタムコードはありません 部門別ポータルにインストールされるカスタムコードやサードパーティソリューションの動作は保証されません テストを目的としているため すべてのサービス DB とコンテンツ DB は Microsoft SQL Server の同じインスタンスに置かれています また 使用 DB は 別の SQL Server インスタンスで管理されます

5 テストを目的としているため BLOB キャッシュは有効になっています 認証モードは NTLM です このテストでは 検索クロールのトラフィックは考慮されていません ただし 進行中の検索クロールの影響を織り 込むために 健全なファームの定義を変更しました 検索クロールの負荷を 10% と見なして SQL Server のグリーンゾーンを 40% と定義しました 同様に 最大 RPS の基準として SQL Server CPU の 80% を使用しました

6 テストのセットアップ ハードウェア 次の表に このテストで使用したコンピューターのハードウェア仕様を示します テストを何回か反復する間にサーバーファームに追加されるフロントエンド Web サーバーは それぞれ同じ仕様に従います フロントエンド Web サーバー アプリケーション サーバー データベースサーバー サーバーモデル PE 2950 PE 2950 Dell PE 6850 プロセッサ 3.19GHz RAM 8 GB 8 GB 32 GB NIC の数 NIC 速度 1 ギガビット 1 ギガビット 1 ギガビット ロードバランサーの種類 F5 - ハードウェアロー 該当なし 該当なし ドバランサー ULS ログレベル ミディアム ミディアム 該当なし 表 1: サーバーコンピューターのハードウェア仕様 ソフトウェア 次の表に このテスト作業で使用したサーバーにインストールされて実行されたソフトウェアの仕様を示します フロントエンド Web アプリケーションサーバー データベースサーバー サーバー オペレーティングシステム Windows Server 2008 R2 x64 Windows Server 2008 R2 x64 Windows Server 2008 x64 ソフトウェア Microsoft Microsoft SharePoint SQL Server 2008 R2 CTP3 バージョン SharePoint WAC WAC ロードバランサー F5 - ハードウェアロード 該当なし 該当なし の種類 バランサー ULS ログレベル ミディアム ミディアム 該当なし ウイルス対策設定 無効 無効 無効 表 2: サーバーコンピューターのソフトウェア仕様

7 トポロジと構成 次のトポロジの図は テストに使用したハードウェア設定を示します テストを反復する間にフロントエンド Web サーバー の数を 1 から 2 3 へと変更しましたが それ以外のトポロジは同じです 図 1: ファームの構成テスト環境に設定したサービスについては 上の図を参照してください ユーザープロファイルサービスや Web 解析などのその他のサービスは設定していません データセットとディスクジオメトリ テストファームには 約 1.62 テラバイトのコンテンツが 異なるサイズの 5 つのコンテンツデータベースに分散して配置さ れました 次の表に データの分散方法を示します コンテンツ DB # コンテンツ DB 36 GB 135 GB 175 GB 1.2 TB 75 GB サイズ サイトの数 Web の数 RAID の構成

8 MDF のスピンドルの数 LDF のスピンドルの数 トランザクションミックス 表 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%

9 リスト - リスト項目の更新と新しい項目の追加 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: テストのトランザクションミックス

10 結果と分析 テストの手法 パフォーマンステストの実行には 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) というツールを作成しました このツールは ユーザーがダウンロードして使用できるように公開されています

11 反復の結果 (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% の使用率に達しました この時点で ファームは の MAX RPS を示しています - 小さなユーザー負荷でも フロントエンド Web サーバーの使用率は常に非常に高く このファームを健全なファームと見なすことはできませんでした テストに使用した負荷とデータセットに対して この構成は実際の展開としては推奨されません - グリーンゾーン の定義に従うと このファームには 実際には グリーンゾーン はありません 負荷が小さい場合でも 常にストレスにさらされています MAX ゾーン については ファームが MAX ゾーン になる最小の負荷で RPS 75 でした - フロントエンド Web サーバーがアプリケーションサーバーと二重の役割を持ってボトルネックになったため 次の反復では アプリケーションサーバーを専用のコンピューターに分離しました パフォーマンスカウンターとグラフさまざまなユーザー負荷段階で 1 X 1 ファームのテスト中にキャプチャされたパフォーマンスカウンターを次に示します ユーザー負荷 RPS 遅延 フロントエンド Web サーバ ー CPU アプリケーションサーバー 該当なし 該当なし 該当なし 該当なし CPU SQL Server CPU パーセンタイル [ 秒 ] パーセンタイル [ 秒 ] 表 5: 1 X 1 ファーム構成のパフォーマンスカウンター

12 グラフ 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% の使用率に達しました この時点で ファームは の MAX RPS を示しています - この構成では RPS が パーセンタイルの遅延が 0.23 秒 フロントエンド Web サーバーの CPU が 56% 程度の使用率の グリーンゾーン が提供されました このことは このファームが健全に約 99 の RPS

13 を提供できることを意味します このファームで提供される MAX ゾーン の RPS は 123 で 遅延は 0.25 秒 フロントエンド Web サーバーの CPU は約 85% 程度の使用率になります - この反復ではフロントエンド Web サーバーの CPU がボトルネックだったため 次の反復では さらにフロントエンド Web サーバーを追加しました - パフォーマンスカウンターとグラフさまざまなユーザー負荷段階で 1 X 1 X 1 ファームのテスト中にキャプチャされたパフォーマンスカウンターを次に示します ユーザー負荷 RPS フロントエンド Web サーバー CPU アプリケーションサー バー CPU SQL Server CPU パーセンタイル の遅延 [ 秒 ] 95 パーセンタイルの遅延 [ 秒 ] 表 6: 1 X 1 X 1 構成のパフォーマンスカウンター グラフ 3: 1 X 1 X 1 構成の RPS と遅延

14 グラフ 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 が パーセンタイルの遅延が 0.37 秒 フロントエンド Web サーバーの CPU が 47% 程度の使用率の グリーンゾーン が提供されました これは このファームが健全に約 191 の RPS を提供できることを意味します このファームで提供される MAX ゾーン の RPS は 291 で 遅延は 0.5 秒 フロントエンド Web サーバーの CPU は約 75% 程度の使用率になります - この反復ではフロントエンド Web サーバーの CPU がボトルネックだったため 次の反復では さらにフロントエンド Web サーバーを追加しました パフォーマンスカウンターとグラフさまざまなユーザー負荷段階で 2 X 1 X 1 ファームのテスト中にキャプチャされたパフォーマンスカウンターを次に示します

15 ユーザー負荷 RPS 遅延 フロントエンド Web サーバー CPU アプリケーションサー バー CPU SQL Server CPU パーセンタイル [ 秒 ] 95 パーセンタイル [ 秒 ] 表 7: 2 X 1 X 1 構成のパフォーマンスカウンター グラフ 5: 2 X 1 X 1 構成の RPS と遅延

16 グラフ 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 が パーセンタイルの遅延が 0.41 秒 SQL Server の CPU が 44% 程度の使用率の グリーンゾーン が提供されました このことは このファームが健全に約 242 の RPS を提供できることを意味します このファームで提供される MAX ゾーン の RPS は 318 で 遅延は 0.5 秒 SQL Server の CPU は 75% 程度の使用率になります - これは このシリーズの最後の構成です

17 パフォーマンスカウンターとグラフ さまざまなユーザー負荷段階で 3 X 1 X 1 ファームのテスト中にキャプチャされたパフォーマンスカウンターを次に示しま す ユーザー負荷 RPS 遅延 フロントエンド Web サーバー CPU アプリケーションサー バー CPU SQL Server CPU パーセンタイル [ 秒 ] 95 パーセンタイル [ 秒 ] 表 8: 3 X 1 X 1 構成のパフォーマンスカウンター グラフ 7: 3 X 1 X 1 構成の RPS と遅延

18 比較 グラフ 8: 3 X 1 X 1 構成のパフォーマンスカウンター 実行した段階テストから 各構成が MAX ゾーンまたはグリーンゾーンになるポイントがわかりました このポイントを表に 示します 次の表とグラフは 上に示したすべての結果の概要です トポロジ 1x1 1x1x1 2x1x1 3x1x1 最大 RPS グリーンゾーンの RPS 該当なし 最大遅延 グリーンゾーンの遅延 表 10: さまざまな構成の結果の概要 グラフ 9: さまざまな構成の RPS の概要

19 グラフ 10: さまざまな構成の遅延の概要ディスク I/O に関するメモこのドキュメントに記載されている推奨事項では ディスク I/O ベースのボトルネックは考慮されていませんが 傾向を観察しておくことに意味はあります 次のような数値になりました 構成 1x1 1x1x1 2x1x1 3x1x1 最大 RPS 読み込み数 / 秒 書き取り数 / 秒 表 11: さまざまな構成での 1 秒あたりの I/O テストを 1 時間実行し 固定のサイト /Web/ ドキュメントライブラリセットのみを稼働したため SQL Server はすべてのデータをキャッシュできました そのため テストで発生した読み取り IO は非常に少なくなりました 書き込み I/O 操作の方が読み取りより多いことがわかります これはテスト手法に基づく人為的な結果であり 実際の展開をよく表すものではないことに注意してください 典型的な部門別ポータルでは 書き込み操作の 3 4 倍の読み取り操作があることが普通です グラフ 11: さまざまな RPS での 1 秒あたりの I/O

20 検索増分クロールを使用したテスト 前述のように これまでのすべてのテストは検索クロールのトラフィックなしで実行されています 実行中の検索クロールがファームのパフォーマンスに及ぼす影響についての情報を提供するために トランザクションミックスに検索クロールのトラフィックを入れて 最大エンドユーザー 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 該当なし ベースラインとの差 (% RPS) 0% 該当なし 83% 88% SQL Server CPU [%] SA SQL Server CPU [%] フロントエンド Web サーバー CPU [%] アプリケーションサーバー CPU [%] クロールのフロントエンド Web サーバー CPU [%] 表 12: 増分検索クロールのテスト結果 グラフ 12: 増分検索クロールのテスト結果

21 重要事項ここでは コンテンツの変更があまり多くないファームの増分クロールについてのみ議論しています 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) です この比率と前述の結果を使用して 特定のファーム構成が健全にサポートできるユーザー数を推測できます

22 ファームの構成 グリーンゾーン の サポートできるユーザーの概数 RPS 1 X 1 X X 1 X X 1 X 表 13: 各構成のユーザー人口の概数 もちろん これが直接当てはまるのは トランザクションミックスとハードウェアがテストで使用されたものと完全に同じ 場合に限ります 実際の部門別ポータルは利用パターンが異なり この比率を直接当てはめることはできませんが 近似的には適用可能と考えられます