Share via


エンタープライズ イントラネット共同作業環境のラボ研究 (SharePoint Server 2010)

 

適用先: SharePoint Server 2010

トピックの最終更新日: 2016-11-30

この記事には、Microsoft SharePoint Server 2010 に基づくエンタープライズ イントラネット共同作業ソリューションのパフォーマンスと容量計画に関するガイダンスが含まれています。主な内容は以下のとおりです。

  • ラボ環境の仕様 (ハードウェア、ファーム トポロジ、構成など)

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

  • 類似の環境を展開するために必要なハードウェア、トポロジ、および構成の決定と、適切な容量とパフォーマンスの特性に合わせた環境の最適化を支援するテスト結果の分析

この記事の内容:

  • この環境の概要

  • 用語集

  • 概要

  • 仕様

  • 結果と分析

この環境の概要

このドキュメントは、Microsoft でのテスト環境に基づいて、SharePoint Server 2010 エンタープライズ イントラネット共同作業ソリューションでサーバーをスケールアウトおよびスケールアップするためのガイダンスを提供します。容量計画では、ハードウェアの購入に関する情報と、ソリューションを最適化するためのシステム構成の作成に関する情報を提供します。

シナリオごとに要件は異なります。つまり、ユーザー独自のハードウェアと環境で追加のテストを実行することでこのガイダンスを補完することが重要です。計画している設計とワークロードがこのドキュメントで説明されている環境と似ている場合、このドキュメントを使用して、環境のスケール アップとスケール アウトに関する結論を引き出すことができます。

このドキュメントの内容は次のとおりです。

  • ハードウェア、トポロジ、および構成を含む仕様

  • ワークロード (ユーザー数を含むファームの需要) と利用状況特性

  • データベース サイズなどのデータセット

  • Web サーバーをスケールアウトするためのテスト結果と分析

  • Web サーバーをスケールアップするためのテスト結果と分析

  • データベース サーバーをスケールアウトするためのテスト結果と分析

  • Web サーバーとデータベース サーバーでの処理量と影響についてのMicrosoft Office SharePoint Server 2007 と SharePoint Server 2010 の比較

このドキュメントで説明する SharePoint Server 2010 環境は、大規模企業の運用環境を模倣するラボ環境です。運用環境は、エンタープライズ共同作業の内部チーム、組織、チーム、およびプロジェクト用の非常に重要なチーム サイトと発行ポータルをホストします。従業員はその運用環境を使用して、プロジェクトの追跡、ドキュメントの共同作業、組織内の情報の共有を行います。環境には、アドホック プロジェクトと小規模なチームで使用される小規模なサイトが非常に多く含まれています。運用環境の詳細については、「企業イントラネット共同作業環境の技術的ケース スタディ (SharePoint Server 2010)」を参照してください。

このドキュメントを読む前に、SharePoint Server 2010 での容量管理の基本的な考え方を必ず理解しておいてください。このドキュメントは、容量管理を行うための推奨アプローチを学習するうえで役立ちます。ここでは、このドキュメントの情報を効果的に利用する方法を理解する際に役に立つ背景情報を提供するほか、このドキュメントで使用されている用語を定義します。

また、次のドキュメントを読むことをお勧めします。

用語集

このドキュメントでは、専門的な用語がいくつか使用されています。以下は、重要な用語とその定義です。

  • RPS: 1 秒あたりの要求数。1 秒間にファームまたはサーバーが受信した要求の数。これはサーバー ロードおよびファーム ロードの一般的な計測基準です。

    要求は、ページ ロードとは異なる点に注意してください。各ページには複数のコンポーネントが含まれ、それらは、ページが読み込まれるときに 1 つまたは複数の要求を作成するからです。したがって、1 つのページ ロードで複数の要求が作成されます。一般的には、認証チェックと、重要ではないリソースを使用するイベントは、RPS 計測ではカウントされません。

  • グリーン ゾーン: これは、サーバーが以下の一連の要件を維持することができる状態です。

    • 要求の 75 % 以上で、サーバー側の待機時間が 1 秒未満。

    • すべてのサーバーの CPU 使用率が 50% 未満。

    注意

    このラボ環境ではアクティブな検索クロールが実行されていなかったので、データベース サーバーの CPU 使用率は 40% 以下に維持され、検索クロール ロードは 10% に維持されていました。ここでは、検索クロール ロードを 10% CPU に制限するために、運用環境で Microsoft SQL Server リソース ガバナーが使用されているものとします。

    • 障害発生率が 0.01% 未満。
  • レッド ゾーン (最大): これは、サーバーが以下の一連の要件を維持することができる状態です。

    • HTTP 要求調整機能が有効であるが、503 エラー (サーバー使用中) が返されない。

    • 障害発生率が 0.1% 未満。

    • 要求の少なくとも 75 % でのサーバー側待機時間が 3 秒以下。

    • データベース サーバーの CPU 使用率が 80% 未満。これにより 10% は検索クロール ロード用に予約できます。この検索クロール ロードは、SQL Server リソース ガバナーを使用して制限されます。

  • AxBxC (グラフの注釈): これは、それぞれ Web サーバー、アプリケーション サーバー、データベースサーバー数を表します。たとえば 8x1x2 は、この環境に 8 つの Web サーバー、1 つのアプリケーション サーバー、2 つのデータベース サーバーが含まれることを意味します。

  • **MDF と LDF:**SQL Server 物理ファイル。詳細については、「ファイルとファイル グループのアーキテクチャ」を参照してください。

概要

このセクションでは、スケーリング方法、このラボ環境と類似のケース スタディ環境との関係、およびテスト方法の概要を示します。

スケーリング方法

このセクションでは、ご使用の環境でサーバーをスケーリングするために推奨する特定の順序について説明します。この順序は、このラボ環境のスケーリングに使用した方法と同じです。以下で示す方法を使用すると、ユーザーのワークロードに最適な構成を見つけることができます。

  • 最初に Web サーバーをスケールアウトしました。この Web サーバーは、テストされたワークロード下でできる限り (データベース サーバーがボトルネックになり、Web サーバーからこれ以上の要求を受けることができなくなるまで) スケールアウトされました。

  • 2 番目に、コンテンツ データベースの半分を別のデータベース サーバーに移動して、データベース サーバーをスケールアウトしました。この時点で、Web サーバーはデータベース サーバーに十分なロードをかけていませんでした。そのため、データベース サーバーがさらにスケールアウトされました。

  • スケールアップをテストするために、Web サーバーをスケールアウトする代わりに Web サーバーをスケールアップする別のオプションを試しました。一般的に、Web サーバーをスケールアウトする方がスケールアップするよりも好まれます。これは、スケールアウトすることにより、冗長性と可用性が向上するためです。

ラボ環境を運用環境に関連付ける

このドキュメントで概説するラボ環境は、Microsoft での運用環境モデルの規模を小さくしたものです。2 つの環境にはかなりの差がありますが、それらを比較して検証することは有用です。これは、両方の環境がエンタープライズ共同作業環境であり、実際のパターンが類似している必要があるためです。

ラボ環境は、運用環境のデータのサブセットを含み、ワークロードが一部変更されています。これにより、Web サーバーのメモリ利用状況に関するテスト結果に影響が出ます。これは、運用環境のオブジェクト キャッシュが固有サイトでの大量のヒットを受信し、より多くのメモリを使用するためです。またラボ環境は、7 テラバイトのデータを持ち越す運用環境とは対照的に、データ量が少なく、その大部分はメモリにキャッシュされます。そのため運用環境上のデータベース サーバーは、ラボ環境のデータベース サーバーより多くのディスク読み取りを実行する必要があります。同様にラボ環境で使用されたハードウェアは、リソースの需要が少ないという点で、モデル化された運用環境とは大幅に異なります。ラボ環境では、より簡単に利用できるハードウェアを使用します。

環境間の違いを詳しく理解するために、このドキュメントの「仕様」セクションを読み、「企業イントラネット共同作業環境の技術的ケース スタディ (SharePoint Server 2010)」に記載されている仕様と比較します。

方法とテストの注意事項

このドキュメントでは、テスト ラボ環境での結果を示します。運用環境ではなくラボ環境を使用したため、ある要因を制御して、このワークロードに対するパフォーマンスの特定の側面を示すことができました。また、ここに一覧表示されている運用環境の特定の要素をラボ環境から外して、テストのオーバーヘッドを簡素化しました。運用環境では、この要素を省略しないことをお勧めします。

  • テストの実行中、その結果の比較を容易にするために、1 度に変更したのは 1 つの変数だけでした。

  • 冗長性はこのテストの目的としては必要なかったので、このラボ環境で使用されたデータベース サーバーはクラスターには含まれていませんでした。

  • 検索クロールはテスト中に実行されませんでしたが、運用環境で実行されていた可能性があります。これを考慮に入れるために、'グリーン ゾーン' と '最大' の定義で、SQL Server CPU 使用率を低くし、検索クロールがテストと同時に実行されていた場合に使用されたリソースを用意しました。詳細については、「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)」を参照してください。

仕様

このセクションでは、ラボ環境のハードウェア、ソフトウェア、トポロジ、および構成の詳細について説明します。

ハードウェア

以下のセクションでは、このラボ環境で使用されたハードウェアについて説明します。

Web およびアプリケーション サーバー

ファーム内に 1 ~ 8 つの Web サーバーがあり、さらに 1 つのアプリケーション サーバーがあります。

Web サーバー WFE1-8 と APP1

プロセッサ

2 クアッド コア 2.33 GHz プロセッサ

RAM

8 GB

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

Windows 2008 Server R2

SharePoint のドライブのサイズ

80 GB

ネットワーク アダプターの数

2

ネットワーク アダプターの速度

1 ギガビット

認証

Windows NTLM

ロード バランサーの種類

Windows NLB

ローカルで実行されているサービス

WFE 1-8: 基本のフェデレーション サービス。これには、タイマー サービス、管理サービス、およびトレース サービスが含まれていました。APP1: Word Automation Services、Excel Services、および SandBoxed Code Services。

データベース サーバー

2 ~ 3 つのデータベース サーバーがあります。2 つまではコンテンツ データベースを保管する既定の SQL Server インスタンスを実行し、1 つはロギング データベースを実行しています。このドキュメントでは、ロギング データベースについては説明しません。

注意

使用状況レポートを有効にしている場合は、ロギング データベースを個別の論理ユニット番号 (LUN) に格納することをお勧めします。大規模な展開と一部の中規模な展開の場合、サーバーの CPU への要求が非常に大きくなる可能性があるため、個別の LUN では対応できません。この場合、ロギング データベース用の個別のデータベース サーバー ボックスが必要になります。このラボ環境では、ロギング データベースは SQL Server の個別のインスタンスに格納されましたが、その仕様はこのドキュメントには含まれていません。

データベース サーバー - 既定のインスタンス DB1-2

プロセッサ

4 デュアルコア 3.19 GHz プロセッサ

RAM

32 GB

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

Windows 2008 Server R2

記憶域とジオメトリ

DAS (Direct Attached Storage)

内部アレイ 5 x 300GB 10krpm ディスク

外部アレイ 15 x 450GB 15krpm ディスク

6 x コンテンツ データ (外部 RAID0、2 つのスピンドル、それぞれ 450GB)

2 x コンテンツ ログ (内部 RAID0、1 つのスピンドル、それぞれ 300GB)

1 x 一時データ (内部 RAID0、2 つのスピンドル、それぞれ 150GB)

1 x 一時ログ (外部 RAID0、2 つのスピンドル、それぞれ 150GB)

2 x バックアップ ドライブ (内部 RAID0、1 つのスピンドル、それぞれ 300GB)

ネットワーク アダプターの数

1

ネットワーク アダプターの速度

1 ギガビット

認証

Windows NTLM

ソフトウェアのバージョン

SQL Server 2008 R2 (プレリリース版)

トポロジ

以下の図は、このラボ環境におけるトポロジを示しています。

このラボ環境のファーム トポロジの図

構成

最適なパフォーマンスを実現するために、このラボ環境で以下の構成変更が行われました。

設定 メモ

サイト コレクション

   

BLOB キャッシュ

ON

既定値は OFF です。BLOB キャッシュを有効にすると、頻繁に要求される可能性のある静的ページ リソースに対するデータベース サーバーの呼び出しが減り、サーバーの効率が向上します。

データベース サーバー - 既定のインスタンス

   

並列処理の最大限度

1

既定値は 0 です。最適なパフォーマンスが得られるように、SharePoint Server データベースをホストするデータベース サーバーでは、並列処理の最大限度を 1 に設定することを強くお勧めします。並列処理の最大限度を設定する方法の詳細については、「max degree of parallelism オプション」(https://go.microsoft.com/fwlink/?linkid=189030&clcid=0x411)」を参照してください。

ワークロード

このドキュメントで説明するラボ環境でのトランザクション ミックスは、Microsoft の運用環境のワークロード特性に似ています。運用環境の詳細については、「企業イントラネット共同作業環境の技術的ケース スタディ (SharePoint Server 2010)」を参照してください。

ここでは、運用環境と比較しながら、SharePoint Server 2010 に対して実行されるラボ テスト ミックスの詳細を示します。ワークロードにはわずかな違いがいくつかありますが、どちらもエンタープライズ共同作業環境での典型的なトランザクション ミックスを表します。

テスト環境のワークロードを示す図

データセット

このドキュメントで説明するラボ環境のデータセットは、Microsoft における運用環境のデータセットのサブセットです。運用環境の詳細については、「企業イントラネット共同作業環境の技術的ケース スタディ (SharePoint Server 2010)」を参照してください。

データセットの特性

データベース サイズ (組み合わせ)

130 GB

BLOB サイズ

108.3 GB

コンテンツ データベースの数

2

サイト コレクションの数

181

Web アプリケーションの数

1

サイトの数

1384

結果と分析

以下の結果は、このドキュメントの「概要」セクションで説明されているスケーリング方法に基づいて整理されています。

Web サーバーのスケールアウト

このセクションでは、このラボ環境の Web サーバー数をスケールアウトした時に得られたテスト結果について説明します。

テスト方法

  • 同じハードウェア仕様の Web サーバーを追加し、ファームの残りは同じ状態に保ちます。

  • RPS、待機時間、およびリソースの使用状況を測定します。

分析

テストから、以下のことがわかりました。

  • 環境で、データベース サーバーごとに 4 つの Web サーバーにスケールアップしました。ただし処理量は、特に 4 番目の Web サーバーを追加したときに非線形に増加しました。

  • 4 つの Web サーバーを追加したあとは、Web サーバーを追加しても処理量は増えませんでした。これは、この時点のボトルネックがデータベース サーバーの CPU 使用率であったためです。

  • テスト全体を通して平均待機時間はほぼ一定で、Web サーバー数と処理数によって影響を受けませんでした。

注意

このセクションで説明している結果はハードウェア固有です。大量のローエンド ハードウェアまたは少数のハイエンド ハードウェアで、同じ処理量を達成できた可能性があります。同様に、データベース サーバーのハードウェアを変えると、結果に影響が出ます。これらの結果に与える影響が Web サーバーのハードウェアによってどの程度違いがあるかを把握するには、「Web サーバーのスケール アップ」セクションを参照してください。

結果のグラフとチャート

以下の図の x 軸は、ファーム内の Web サーバー数の変化 (1 つの Web サーバー (1x1x1) から 5 つの Web サーバー (5x1x1) への拡大) を示します。

1. 待機時間と RPS

以下の図は、スケールアウト (Web サーバーの追加) が待機時間と RPS にどのような影響を与えるかを示します。

WFE スケール アウト全体での RPS と待機時間を示す図

2. プロセッサの使用率

以下の図は、Web サーバーのスケールアウトが Web サーバーとデータベース サーバー上のプロセッサの使用率にどのような影響を与えるかを示します。

WFE スケール アウトでのプロセッサ使用率を示す図

3. MDF および LDF ファイルでの SQL Server の IOPS (セクションごとの I/O 操作数)

以下の図は、Web サーバー数がスケール アウトされるときに、コンテンツ データベースの IOPS がどのように変わるかを示します。これらは、以下のパフォーマンス カウンターを見て判断されます。

  • PhysicalDisk: Disk Reads / sec

  • PhysicalDisk: Disk Writes / sec

このラボ環境では、IOPS に関するデータは運用環境を表すものではないと考えました。これはこのデータセットが非常に小さく、モデル化している運用環境に入れることができるデータセットよりも多くのデータセットをキャッシュ内に入れることができるためです。予測される読み取り数は、ラボから取得した書き込み数/秒のデータ値に、運用環境での読み取り数と書き込み数の比率を掛けることによって計算しました。このセクションでの結果は平均です。しかし、特定の操作中に発生する考慮しなければならないスパイクも存在します。必要な IOPS を予測する方法については、「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)」を参照してください。

最大:

マックスゾーンへの Web サーバー スケール アウトでの IOP 数を示す図

グリーン ゾーン:

グリーンゾーンへの Web サーバー スケール アウトでの IOP 数を示す図

これらの図をどのように読み取るかの例:

このドキュメントに記載されているものに似たワークロードを持ち、300 RPS がグリーン ゾーンになると予測される組織では、3x1x1 トポロジを使用することができ、また MDF ファイルでおよそ 600 PhysicalDisk reads/sec を使用します。

データベース サーバーのスケールアウト

このセクションでは、このラボ環境でデータベース サーバー数をスケールアウトした時に得られたテスト結果について説明します。

テスト方法

  • 1 つのデータベース サーバーに 2 つのコンテンツ データベースを配置し、それらを 2 つのサーバーに分割して、環境内のデータベース サーバーで利用できるプロセッサ コアとメモリを効果的に 2 倍にします。

  • データベース サーバーを追加しているときでも、IOPS の総数を一定に保ちます。これは、コンテンツを 1 つのデータベース サーバーではなく 2 つのデータベース サーバーに分割しても、コンテンツ データベースごとにディスクが実行できる読み取り数/秒と書き込み数/秒は変わらなかったためです。

分析

  • 4x1x2 環境の最初のボトルネックは、データベース サーバーの CPU 使用率でした。プロセッサとメモリを追加したときに、ほぼ直線的なスケーリングがありました。

  • 4 つの Web サーバーと 2 つのデータベース サーバーにスケーリングしても、RPS は大幅に増えませんでした。これは Web サーバー上の CPU 使用率がほぼ 100% だったためです。

  • (1 つのデータベース サーバーを追加することによって) データベース サーバーをスケールアウトし、4 つの Web サーバーを追加すると、パフォーマンスはほぼ直線的にスケーリングしました。その時点のボトルネックは、データベース サーバーの CPU 使用率からコンテンツ データベースのディスク IPOs にシフトしました。

  • これまでの 8x1x2 をスケールアウトするために、このラボ環境では追加テストは実行されませんでした。しかし、追加の IOPS によって処理量がさらに増えると予測しています。

  • テストで使用した IOPS と達成した RPS 間の相互関係が認められました。

結果のグラフとチャート

以下の図では、x 軸は 4 つの Web サーバー、1 つのアプリケーション サーバー、および 1 つのデータベース サーバー (4x1x1) が 8 つの Web サーバー、2 つのデータベース サーバー (8x1x2) にスケール アウトしたことを示しています。一部は 1x1x1 または 4x1x2 も示します。

1. 待機時間と RPS

以下の図は、Web サーバーとデータベース サーバーの両方をスケールアウトすると待機時間と RPS にどのような影響を与えるかを示します。

データベース スケール アウトでの RPS と待機時間を示す図

2. プロセッサの使用率

以下の図は、スケール アウトがプロセッサの使用率にどのような影響を与えるかを示します。

データベース スケール アウトでのプロセッサ使用率を示す図

3. スケールアウト時のメモリの使用率

テスト全体を通して、環境内のサイト コレクション数が多くなれば、使用されるメモリも多くなることを確認しました。たとえば 181 のサイト コレクションにアクセスしたテストでは、主要な w3wp プロセスが 1.8 GB RAM のほとんどを使用しました。その他の例については、「パフォーマンスと容量に関する技術的なケース スタディ (SharePoint Server 2010)」を参照してください。増加したサイト コレクション数に対応するメモリ要件に関するその他のコンテンツは現在作成中です。新規コンテンツや更新されたコンテンツをチェックしてください。

4. MDF および LDF ファイルでの SQL Server の IOPS (セクションごとの I/O 操作数)

以下の図では、Web サーバー数とデータベース サーバー数がスケールアウトされたときに IOPS がどのように変化するかを示しています。

最大 RPS

マックスゾーンへのデータベース スケール アウトでの IOP 数を示す図

グリーン ゾーン RPS

グリーンゾーンへのデータベース スケール アウトでの IOP 数を示す図

Web サーバーのスケールアップ

このセクションでは、このラボ環境の Web サーバーをスケールアップするときに得られたテスト結果について説明します。

テスト方法

  • Web サーバー プロセッサを追加しますが、ファームの残りは同じ状態にします。

分析

  • スケーリングは 8 つのプロセッサ コアまで直線的です。

  • テストは、環境で 24 コア ボックスを利用できることを示します。ただし、24 個のコアにアプローチすると低下が発生します。

結果のグラフとチャート

以下の図の X 軸は、Web サーバー上のプロセッサ数と RAM の容量です。以下のグラフは、スケールアップ (プロセッサの追加) が Web サーバー上の RPS にどのような影響を与えるかを示します。

スケール アップでの RPS を示す図

SharePoint Server 2010 と Office SharePoint Server 2007 の比較

このセクションでは、このワークロードの容量テストが SharePoint Server 2010 と Microsoft Office SharePoint Server 2007 の間でどのように異なるかについて説明します。

ワークロード

SharePoint Server 2010 と Office SharePoint Server 2007 を比較するために、「仕様」セクションで概説しているものとは異なるテスト ミックスが使用されました。これは、一部の SharePoint Server 2010 操作を Office SharePoint Server 2007 で利用できなかったためです。Office SharePoint Server 2007 のテスト ミックスは、SharePoint Server 2010 テストが使用する同じ運用環境から始まります。ただし、これは、その環境の SharePoint Server 2010 へのアップグレード前に記されたものです。

以下の図は、Office SharePoint Server 2007 のラボ環境と運用環境のテスト ミックスを示しています。

環境に合わせたトランザクションの混合を示す図

テスト方法

  • この比較のためのテストは、Office SharePoint Server 2007 環境を作成し、それをこのセクションの前半で概説したワークロードでテストし、次にその環境を使用するクライアントの変更やビジュアル アップグレードを行わずに SharePoint Server 2010 にコンテンツ データベースをアップグレードして実行されました。このアップグレードされた環境は、SharePoint Server 2010 での結果を出すために、Office SharePoint Server 2007 操作のみを含む同じテスト ミックスを使用して再テストされました。

  • SharePoint Server 2010 テスト用のコンテンツ データベース アップグレード後は、データベースは変更されませんでした。

  • Office SharePoint Server 2007 のテスト ミックスは、SharePoint Server 2010 固有の新しい操作をすべて除外し、Office SharePoint Server 2007 用の同じ運用環境上のエンタープライズ イントラネット共同作業ソリューションに似ています。これについては「ワークロード」セクションで説明しています。

分析

  • 同じ数の Web サーバーが、SharePoint Server 2010 と Office SharePoint Server 2007 での最大処理量まで負荷を掛けられている場合、SharePoint Server 2010 が達成する処理量は Office SharePoint Server 2007 と比較して 20% 少なくなります。

  • Web サーバーがスケールアウトされて、データベース サーバーの使用量が最大になると、SharePoint Server 2010 が達成できる処理量は、Office SharePoint Server 2007 と比較して 25% 多くなりました。これは、大規模な展開を維持するために SharePoint Server 2010 で行われた機能強化を反映しています。

  • Web サーバーがスケールアウトされてデータベース サーバーの使用量が最大になると、SharePoint Server 2010 が SQL Server の CPU 使用率の限度になり、Office SharePoint Server 2007 がデータベース層でのロックの限度になりました。つまりデータベース サーバーで利用できる処理能力が増加すると、SharePoint Server 2010 は、Office SharePoint Server 2007 を使用する同じハードウェアで達成できるよりも多くの処理量を達成できます。これは、向上したハードウェアによって影響を受けない、Office SharePoint Server 2007 内のデータベースのロック メカニズムが要因です。そのため、データベース サーバーの CPU 使用率を 80% より高くすることはできませんでした。

  • このセクションの前半で概説した所見の結果、Office SharePoint Server 2007 では、可能な最大処理量は 5x0x1 トロポジで達成され、SharePoint Server 2010 では同じワークロードでの可能な最大処理量は 7x0x1 トポロジで達成されました。さらに、総 RPS が 25% 増加しました。

結果のグラフとチャート

以下の図では、Web サーバーをスケールアウトしない場合の処理量を示しています。

スケール アウト前のスループットを示す図

以下の図は、Web サーバーが最大のスケールアウト時の処理量を示しています。

最大 Web サーバー スケール アウトでのスループットを示す図

See Also

Other Resources

リソース センター: SharePoint Server 2010 の容量の管理