SharePoint Server 2010 でエンタープライズ管理されたメタデータの容量とパフォーマンスを見積もる

 

適用先: SharePoint Server 2010

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

この記事では、Microsoft SharePoint Server 2010 における Managed Metadata Service のサイズ変更およびパフォーマンスの最適化に関する推奨事項について説明します。また、この記事では、最大のパフォーマンスが発揮されるようにサービスを構成し、サービス アプリケーション データベースを構築する方法について、ベスト プラクティスを提供します。

この記事の情報は、Managed Metadata Service のパフォーマンスと容量に関するテスト済みの制限を把握するのに役立つ可能性があります。この情報を利用して、計画中の展開が、許容できるパフォーマンスと容量の制限内に収まるかどうかを判断します。

この記事の内容:

• テスト ファームの諸特性

• テスト結果と推奨事項

容量管理および SharePoint Server 2010 の計画方法に関する一般的な情報については、「SharePoint Server 2010 での容量管理と規模設定」を参照してください。

テスト ファームの諸特性

データセット

テストは最初にベースライン データセットに対して実行されました。ベースライン データセットは、顧客の標準的なデータセットをシミュレートするものです。次に、1 つの変数を変更し、同じテストを再度実行して、その変数の変更によるパフォーマンスへの影響が確認されました。ほとんどの場合で、変数は個別にテストされました。ただし、場合によって、特定の重要な変数は、組み合わせてテストされました。

ベースライン データセット

ベースライン データセットには、次の表に示すデータが含まれます。

データ	詳細
用語セット グループ数	100
用語セット数	1,000 (1 グループあたり 10)
管理された用語数 (エンタープライズ キーワードは含まれません)	20,000 (用語セットあたり 20)
エンタープライズ キーワード	80,000
合計用語数 (管理された用語とエンタープライズ キーワードが含まれます)	100,000
ラベル数	100,000 (用語あたり 1)
用語ラベルの長さ	1 ラベルあたり 250 文字

ベースライン データセット内の用語数を次のグラフに示します。

これらのテストでは、すべてのデータセットにおいて、キーワードと管理された用語の比率が常に 4:1 に維持されました。

ワークロード

Managed Metadata Service のいくつかの主な特性がサービスのパフォーマンスに潜在的に影響する可能性があります。その特性は以下のとおりです。

• サービス内のデータの特性

  • 用語ラベルの長さ

  • 1 用語ストアあたりの用語数

  • 1 用語ストアあたりの用語ラベル数

• サービスに対するロードの特性

  • 読み取り/書き込みミックス

• 用語ストアのキャッシュ サイズ

• 1 データベース サーバーあたりのサービス アプリケーション数

• サービス タイマー ジョブ (コンテンツ タイプ ハブ、コンテンツ タイプの購読、エンタープライズ メタデータ サイト データの更新、分類更新スケジューラ) のパフォーマンス

この記事で示す容量とパフォーマンスに関する特定のテスト結果は、現実の環境におけるテスト結果とは異なる場合があります。この記事のテスト結果は、ある一定規模の環境を設計するための出発点を提供することを目的とします。初期のシステム設計が完了した後、構成をテストし、実際の環境の Managed Metadata Service の構成をシステムがサポートするかどうかを判断します。

テスト シナリオ

各テスト シナリオで以下のテストが使用されました。

• 用語を作成する (書き込みテスト)

  既存の用語セットに用語を作成します。

• 候補を取得する (読み取り専用テスト)

  1 文字の文字列で始まる用語を検索します。キーワード フィールドの候補の取得で使用されます。

• 一致を取得する (読み取り専用テスト)

  提供された文字列に一致する用語を検索します。キーワード フィールドまたはメタデータ フィールドの値の一致で使用されます。

• ページングを使用して、用語セットの子の用語を取得する (読み取り専用テスト)

  ページングを使用して、用語セットの子の用語を取得します。

• 用語を確認する (読み取り専用テスト)

  1 つの用語を確認します。キーワード フィールドまたはメタデータ フィールドの値の確認で使用されます。

テスト ミックス

ほとんどのテスト (書き込み操作の影響テストを除く) で、次の表に示された、読み取り操作と書き込み操作の同じミックスが使用されました。

テスト	ミックスの割合
用語を作成する	0.125%
候補を取得する	72.875%
一致を取得する	11%
ページングを使用して、用語セットの子の用語を取得する	5%
用語を確認する	11%

"候補を取得する" は、最もよく使用されるエンドユーザー操作です。したがって、テスト ミックスの中でこのテストに重点が置かれています。

ハードウェア、設定、およびトポロジ

テスト ファームは、Web サーバー、アプリケーション サーバー、およびデータベース コンピューターごとに 1 つの独立したサーバーを使用する、3 つのサーバーで構成されるファームです。

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

Web サーバーとアプリケーション サーバーには同じハードウェアが使用されました。構成は次の表のとおりです。

コンポーネント	Web サーバーとアプリケーション サーバーの構成
プロセッサ	2 クアッド コア 2.33 GHz
RAM	8 GB
オペレーティング システム	Windows Server 2008、64 ビット版
システム ドライブのサイズ	300 GB
ネットワーク アダプターの数	2
ネットワーク アダプターの速度	1 秒あたり 1 ギガビット
認証	Windows 基本
ソフトウェアのバージョン	SharePoint Server 2010 注意 使用するバージョンによって結果が異なる場合があります。
ローカルで実行されているサービス	サーバーの全体管理 Microsoft SharePoint Foundation 受信電子メール Microsoft SharePoint Foundation Web アプリケーション Microsoft SharePoint Foundation Microsoft SharePoint Foundation Workflow Timer Service

データベース サーバー

データベース サーバーは次の表で示されたように構成されました。

コンポーネント	データベース サーバーの構成
プロセッサ	4 クアッド コア 3.19 GHz
RAM	16 GB
オペレーティング システム	Windows Server 2008、64 ビット版
記憶域	300 GB のディスク 15 台、各 15,000 RPM
ネットワーク アダプターの数	2
ネットワーク アダプターの速度	1 秒あたり 1 ギガビット
認証	Windows NTLM
ソフトウェアのバージョン	Microsoft SQL Server 2008

テスト結果と推奨事項

このセクションでは、以下の各特性に関するテスト結果と推奨事項について説明します。

• データ特性

• ロード特性

• タイマー ジョブのパフォーマンス

データ特性

用語ラベルの長さの影響

これらのテストは、ベースラインの用語ストアに対して、最初に 5 文字の用語ラベルの長さを使用して実行され、次に 250 文字の用語ラベルの長さを使用して再度実行されました。このテストでは、他のほとんどのテストで使用した読み取り操作と書き込み操作のミックスよりも、全体の中の書き込み操作の割合が非常に高くなっています。

テスト	ミックスの割合
用語を作成する	5%
候補を取得する	70%
一致を取得する	10%
ページングを使用して、用語セットの子の用語を取得する	5%
用語を確認する	10%

用語ラベルの各長さに対する 1 秒あたりの要求数 (RPS) の結果を次のグラフに示します。このデータは、両方のロードにおいて、用語ラベルの長さは平均 RPS にほとんど影響しないことを示しています。

CPU とメモリの使用量を次のグラフに示します。

結果が示すとおり、用語ラベルの長さが Web サーバーとアプリケーション サーバーの CPU とメモリの使用量に与える影響はほとんどありません。ただし、データベース サーバーのロードは用語ラベルの長さが長くなるにつれて増大します。

結論と推奨事項: 用語ラベルの長さ

用語ラベルの長さはシステムのパフォーマンスに重大な影響を与えません。

用語ストアあたりの用語数

これらのテストはベースラインの用語ストアで実行されました。その後、管理される用語とキーワードの数を比例的に増加することで、用語ストアが 100 万用語までスケール アップされました。

テスト用の用語ストアからキーワード用語セットが削除されたときに、次の 2 つのグラフに示されているとおり、100,000 用語を含む用語ストア、500,000 用語を含む用語ストア、100 万用語を含む用語ストアの間でパフォーマンスに大きな違いはありませんでした。

指定されたテスト ロードの下にシステムが置かれると、キーワードの数が 16,000 から 800,000 に増加するにつれて、キーワードの作成に要する時間が大幅に増加します。この傾向は次のグラフで確認できます。

結論と推奨事項: 用語ストアあたりの用語数

キーワードを作成するユーザーがほとんどいない場合や、キーワードの数が少ない場合、用語ストア内の用語数はシステムのパフォーマンスに重大な影響を与えません。

より複雑な構造を持つ他の用語セットと異なり、キーワード用語セットはフラット リストに保管されます。このフラット リストが増大すると、同じ名前のキーワードが既に存在するかどうかを確認する時間が長くなります。したがって、大きいキーワード用語セットでは、キーワードを作成する時間が長くなります。

用語ストアの管理者は、キーワード用語セットのサイズを制限して、ユーザーがキーワード用語を作成するときの遅延を回避する必要があります。1 つの方法として、キーワードを通常の用語セットに頻繁に移動する方法があります。これにより、パフォーマンスが向上し、用語データが適切に整理されます。

フラット リストに 150,000 を超える用語が含まれる用語セットでは、遅延とパフォーマンスの問題に直面します。1 つの代替手段として、管理された用語セットを使用する方法があります。管理された用語セットには、通常、構造化された用語のコレクションがあります。用語セットの詳細については、「管理されたメタデータの概要」を参照してください。

一般的なエラー

用語ストア内の用語の総数が 500,000 に近づくと、ユーザーは用語ストアへのアクセスを試みるときにさまざまな例外に直面する場合があります。関連する統合ログ サービス (ULS) ログを確認することで、ファーム管理者は、例外を発見し、例外がクライアントまたはサーバーのどちらに適用されるかを確認できます。

TimeoutException

TimeoutException エラーが発生した場合、Managed Metadata Service の client.config ファイルまたは web.config ファイル内にあるタイムアウト値を変更できます。client.config ファイルは、%PROGRAMFILES%\Microsoft Office Servers\14.0\WebClients\Metadata フォルダーにあります。web.config ファイルは、%PROGRAMFILES%\Microsoft Office Servers\14.0\WebServices\Metadata フォルダーにあります。以下の 4 つのタイムアウト値があります。

• receiveTimeout。受信操作を完了するために与えられるインターバルを指定するタイムアウト値。

• sendTimeout。送信操作を完了するために与えられるインターバルを指定するタイムアウト値。

• openTimeout。開く操作を完了するために与えられるインターバルを指定するタイムアウト値。

• closeTimeout。終了操作を完了するために与えられるインターバルを指定するタイムアウト値。

これらのタイムアウト値は customBinding セクションに定義されます。タイムアウトが発生する特定の操作に基づいてタイムアウト値を増加できます。たとえば、メッセージを受信するときにタイムアウトが発生する場合、ReceiveTimeout の値を増加するだけで済みます。

タイムアウト値の詳細については、「<customBinding>」(https://go.microsoft.com/fwlink/?linkid=214213&clcid=0x411) を参照してください。

ThreadAbortException

ThreadAbortException エラーが発生した場合、特定の Web アプリケーションの web.config ファイル内にある実行タイムアウト値を増加できます。web.config ファイルは、%inetpub%\wwwroot\wss\VirtualDirectories\<アプリケーション ポート番号> フォルダーにあります。たとえば、Web アプリケーションでの TaxonomyInternalService に対する要求の場合、まず、Web アプリケーションの web.config ファイルを特定し、次のコードを構成ノードに追加します。

  <location path="_vti_bin/TaxonomyInternalService.json">
    <system.web>
      <httpRuntime executionTimeout="3600" />
    </system.web>
  </location>

用語ストアあたりの用語ラベル数

このテストは、100,000 用語を含むベースライン用語ストアで実行されました。テスト中に、次のグラフに示されているとおり、各用語のラベル数を増加しました。

ラベル数が増加しても、平均 RPS は若干減少するだけです。次のグラフに示されているとおり、Web サーバー、アプリケーション サーバー、およびデータベース サーバーの CPU とメモリの使用量は若干増加するだけです。

結論と推奨事項: 用語ストアあたりの用語ラベル数

用語あたりの平均ラベル数が 4 個未満の場合、ラベル数はシステムのパフォーマンスに重大な影響を与えません。

概要: データ特性

このセクションでは、用語ストア データの 3 つの異なる特性 (用語ラベルの長さ、用語ストアあたりの用語数、用語ストアあたりの用語ラベル数) についてのテスト結果をレビューします。このテストによって、以下のような傾向が明らかになりました。

• 用語ラベルの長さが 250 に増加しても、用語ストアのパフォーマンスに重大な影響はありません。

• 用語あたりの平均ラベル数が 4 に増加しても、用語ストアのパフォーマンスに重大な影響はありません。

• 用語数が 100 万に増加しても、用語ストアのパフォーマンスに重大な影響はありません。

• フラット リストを使用する、用語ストアの用語セットに 150,000 を超える用語が含まれる場合、新しい用語を用語ストアに追加する時間が長くなる可能性があります。

ロード特性

読み取り/書き込みミックスの変更による影響

これらのテストの実行には、"分類アイテムを作成する" テストを変更するアイテムとして、ベースラインの読み取り/書き込み操作のテスト ミックスが使用されました。次の表に、ベースラインのテスト ミックスで使用された特定の操作、およびそれらに関連付けられた割合を示します。

テスト	ロードの割合
候補を取得する	73%
分類アイテムを作成する	0%
一致を取得する	11%
用語セット内でページ化された子の用語を取得する	5%
用語を確認する	11%

連続する各テストで、作成する用語の数を増加しました。次の表に、実行した 3 つの各テストについて、1 分あたりに作成された平均用語数と平均 RPS を示します。

1 分あたりに作成された平均用語数	平均 RPS
0	182
8.4	157
20	139

次のグラフに示されているとおり、1 分あたりに作成された平均用語数が増加するにつれて RPS は減少します。

CPU とメモリの使用量を次の 2 つのグラフに示します。

結論と推奨事項: 読み取り/書き込みミックスの変更による影響

書き込み操作の割合が増加すると、用語ストアのパフォーマンスが低下することが予想されます。書き込み操作では、データに対してより多くの排他ロックが保持され、読み取り操作の実行が遅延するためです。テスト データによると、作成される平均用語数が 1 分あたり 20 個に達するまで、RPS が大幅に低下することはありません。ただし、1 分あたりの平均用語作成数の 20 という値は十分に高い数値であり、特に、成熟した用語セットでは、通常発生する値ではありません。用語セットを読み取り専用にすると、書き込み操作が排除されてパフォーマンスが向上する可能性があります。

用語ストアのキャッシュ

用語ストアのキャッシュはファーム内のすべての Web サーバーに存在します。このキャッシュには、用語セット グループ、用語セット、および用語を含めることができます。これらのテストは、用語数が増加するにつれて、キャッシュ オブジェクトのメモリの占有領域がどのように変化するかを示すために実行されました。キャッシュ サイズに影響する他の要因があります。たとえば、用語の説明、ラベル数、カスタム プロパティです。テストを簡素化するために、ベースライン用語ストア内のすべての用語に説明またはカスタム プロパティは含まれていません。250 文字の 1 つのラベルのみが含まれます。

次のグラフは、キャッシュ内の用語数が増加するにつれて、メモリの占有領域がどのように変化するかを示しています。

結論と推奨事項: 用語ストアのキャッシュ

キャッシュ内の用語数が増加するにつれて、Web サーバーのメモリ使用量は直線的に増加します。用語数が把握されている場合、これにより、キャッシュ サイズを見積もることができます。テスト データによると、ほとんどのシステムで、メモリの使用量はパフォーマンスの問題になりません。

ファームで使用されるサービス アプリケーション

このテストでは、1 つの Managed Metadata Service アプリケーションと、同じデータベース サーバー上でデータベースをホストする 2 つの Managed Metadata Service アプリケーションとのパフォーマンスの違いが示されます。

次のグラフに示されているとおり、同じロードの下で、サービス アプリケーションが追加されると、RPS は減少します。サービス アプリケーションが追加されると、RPS は減少することが予想されます。

サービス アプリケーションが追加されても、ほとんどの操作の待機時間は重大な影響を受けません。ただし、他の操作と異なり、"候補を取得する" 操作は、利用可能なすべてのサービス アプリケーションと対話的にやりとりします。したがって、次のグラフに示されているとおり、サービス アプリケーションの数が増加するにつれて、この操作の待機時間は増加します。サービス アプリケーションの数が増加するにつれて、この傾向は続くと予想されます。

次のグラフに示されているとおり、同じサーバー上に存在するデータベースを持つ 2 つのサービス アプリケーションがある場合、データベース サーバーの CPU 使用率は大きく増加しますが、メモリの使用量は大きく増加しません。

結論と推奨事項: ファームで使用されるサービス アプリケーション

複数の Managed Metadata Service アプリケーションを維持する必要がある場合、キーワード候補の操作に対する遅延が許容できるレベルであることを確認します。ネットワークの遅延は、全体的な有効遅延の一因にもなります。Managed Metadata Service アプリケーションを可能な限り統合することをお勧めします。

1 つの SQL Server コンピューターを使用してすべてのサービス アプリケーションをホストする場合、サーバーに十分な CPU とメモリ リソースを搭載し、許容できるパフォーマンス目標をサポートする必要があります。

タイマー ジョブのパフォーマンス

このセクションでは、Managed Metadata Service 内の 2 つのタイマー ジョブ、コンテンツ タイプの購読タイマー ジョブと分類更新スケジューラ タイマー ジョブのパフォーマンス特性を示します。この 2 つのタイマー ジョブは、特定の Web アプリケーション内のサイト コレクションを列挙するため、潜在的に長時間動作する可能性があり、大規模ファームでは大量のシステム リソースを消費する可能性があります。

コンテンツ タイプの購読タイマー ジョブ

コンテンツ タイプの購読タイマー ジョブでは、公開コンテンツ タイプが Web アプリケーションのすべての適切なサイト コレクションに配布されます。このタイマー ジョブの総実行時間は、配布する必要のあるコンテンツ タイプの数、コンテンツ タイプ内のフィールドの数と型、サイト コレクションの数など、多くの要因に依存します。このテストでは、以下のスケール ファクターがコンテンツ タイプの総配布時間にどのような影響を与えるかが示されます。

• Web アプリケーション内のサイト コレクションの数

• コンテンツ タイプの数

最初のテストでは、10 個のコンテンツ タイプが発行されて、さまざまな数のサイト コレクションに配布されました。次のグラフに示されているとおり、コンテンツ タイプの配布にかかる時間とサイト コレクションの数との関係はほぼ直線的です。

このテストでは、1 個のコンテンツ タイプが 1,000 のサイト コレクションに発行された後、10 個のコンテンツ タイプが 1,000 のサイト コレクションに発行されました。10 個のコンテンツ タイプの配布時間は、1 個のコンテンツ タイプの配布時間のおよそ 10 倍であり、これもほぼ直線的な増加を示しています。

結論と推奨事項: コンテンツ タイプの購読タイマー ジョブ

テスト結果は、1 つのコンテンツ タイプを 1 つのサイト コレクションに配布するための平均時間はほぼ一定であることを示しています。したがって、サイト コレクションの大規模コレクションでこのタイマー ジョブを実行しても安全です。サイト コレクションの数と、配布するコンテンツ タイプの数が提供されていると、平均配布時間を使用してタイマー ジョブの実行にかかる時間を見積もることができます。これらの数字が非常に大きい場合、タイマー ジョブを実行するのに数時間または数日かかる可能性があります。ただし、このタイマー ジョブは一時停止して再開することができるほか、コンテンツ タイプの発行は頻繁に行われる活動ではありません。

タイマー ジョブ中にコンテンツ タイプのプッシュダウンが実行される場合 (特に多くのリストが関連する場合)、このタイマー ジョブの実行に要する時間が大幅に増加する可能性があります。コンテンツ タイプのプッシュダウンの詳細については、「メタデータ サービス アプリケーションについて」の「管理されたメタデータ接続」を参照してください。

分類更新スケジューラ タイマー ジョブ

分類更新スケジューラ タイマー ジョブでは、Web アプリケーションのすべてのサイト コレクション上にある非表示の分類リストが用語ストアと同期されます。このタイマー ジョブの総実行時間は、更新する必要のあるアイテムの数、および更新するアイテムが含まれるサイト コレクションの数に依存します。このテストでは、Web アプリケーション内の非表示リストのサイズとサイト コレクションの数がサイト コレクションの 1 つのアイテムの平均更新時間にどのように影響するかが示されます。

次のグラフは、サイト コレクションの数と、1 つのサイト コレクション内の 1 つの用語の平均更新時間との関係を示しています。

次のグラフに示されているとおり、非表示リストのサイズが増大するにつれて、1 つのサイト コレクション内の 1 つの用語を更新するのにかかる平均時間は若干増加します。

結論と推奨事項: 分類更新スケジューラ タイマー ジョブ

サイト コレクションの数が増加しても、1 つのサイト コレクション内の 1 つの用語の平均更新時間に重大な影響はありません。したがって、大量のサイト コレクションを持つ Web アプリケーションでこのタイマー ジョブを実行しても安全です。サイト コレクション内の用語の平均更新時間にサイト コレクション数および各サイト コレクション内の更新用語数の平均を掛けることで、タイマー ジョブの総実行時間を見積もることができます。また、このタイマー ジョブは一時停止して再開することもできます。

時間の経過とともに、サイト コレクションで使用される用語の数が増加するにつれて、非表示の分類リストのサイズは増加します。非表示リストのサイズが増大すると、タイマー ジョブの実行時間は長くなる場合があります。