次の方法で共有

PerformancePoint Services のパフォーマンスと容量の要件を見積もる

  • [アーティクル]

 

適用先: SharePoint Server 2010

トピックの最終更新日: 2017-01-18

ここでは、PerformancePoint Services を使用した場合、Microsoft SharePoint Server 2010 が実行されているトポロジにどのような影響があるかについて説明します。

注意

この記事で示す特定の処理能力とパフォーマンスの数値は、現実の環境における数値とは一致しない点に注意することが重要です。ここで示す数値は、ある一定規模の環境を設計する出発点を提供することを目的としています。最初のシステム設計が終了したら、構成をテストして、実際の環境におけるさまざまな要素にシステムが対応できるかどうかを判断するために構成をテストしてください。

この記事の内容

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

  • テスト結果

  • 推奨事項

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

テスト ファームの諸特性

データセット

データセットは、SharePoint Server 2010 および PerformancePoint Services を使用して構築された企業ポータルで構成され、1 つの中規模ダッシュボードが含まれていました。ダッシュボードには 2 つのフィルターがあり、1 つのスコアカード、2 つのグラフ、および 1 つのグリッドにリンクしていました。ダッシュボードは 1 つの Microsoft SQL Server 2008 Analysis Services (SSAS) データ ソースに基づいており、このデータソースでは、SQL Server 2008 Analysis Services キューブの AdventureWorks サンプル データベースが使用されました。

次の表では、ダッシュボード内の各要素の種類と規模について説明します。

名前 説明 規模

フィルター 1

メンバー選択フィルター

7 ディメンション メンバー

フィルター 2

メンバー選択フィルター

20 ディメンション メンバー

スコアカード

スコアカード

15 ディメンション メンバー行、4 列 (2 KPI)

グラフ 1

折れ線グラフ

3 系列、12 列

グラフ 2

積み上げ棒グラフ

37 系列、3 列

グリッド

分析グリッド

5 行、3 列

中規模ダッシュボードで使用されているテンプレートは [ヘッダー、2 列] で、ダッシュボード アイテムのサイズは自動調整またはダッシュボードの特定の割合に設定されました。また、Web ブラウザーのウィンドウ サイズの違いをシミュレートするために、ダッシュボードの各アイテムが 400 ～ 500 ピクセルの範囲内のランダムな高さと幅でレンダリングされました。グラフのレンダリングは Web ブラウザーのウィンドウ サイズに基づいて行われるので、各ダッシュボード アイテムの高さと幅を変更することが重要です。

テスト シナリオとプロセス

このセクションではテスト シナリオを定義し、各シナリオで使用されたテスト プロセスについて説明します。テスト結果、特定のパラメーターなどの詳細情報については、この記事で後述する「テスト結果」を参照してください。

テスト名 テストの説明

ダッシュボードをレンダリングし、2 つのフィルターのどちらかをランダムに 5 回変更します。操作と操作の間には 15 秒の一時停止時間を確保します。

  1. ダッシュボードをレンダリングします。

  2. 2 つのフィルターのどちらかを選択し、フィルター値をランダムに選択して、ダッシュボードが再レンダリングされるまで待ちます。

  3. この操作をあと 4 回繰り返して、2 つのフィルターのどちらかと、ランダム フィルター値をランダムに選択します。

ダッシュボードをレンダリングし、グラフを選択して、それを 5 回展開したり折りたたんだりします。操作と操作の間には 15 秒の一時停止時間を確保します。

  1. ダッシュボードをレンダリングします。

  2. グラフでランダム メンバーを選択し、それを展開します。

  3. グラフで他のランダム メンバーを選択し、それを折りたたみます。

  4. グラフで他のランダム メンバーを選択し、それを展開します。

  5. グラフで他のランダム メンバーを選択し、折りたたみます。

ダッシュボードをレンダリングし、グリッドを選択して、それを 5 回展開したり折りたたんだりします。操作と操作の間には 15 秒の一時停止時間を確保します。

  1. ダッシュボードをレンダリングします。グリッドでランダム メンバーを選択し、そのメンバーを展開します。

  2. グリッドで他のランダム メンバーを選択し、それを展開します。

  3. グリッドで他のランダム メンバーを選択し、それを折りたたみます。

  4. グリッドで他のランダム メンバーを選択し、それを展開します。

1 つのテスト ミックスが使用され、このテスト ミックスを構成するテストは次の割合で開始されました。

テスト名 テスト ミックス

ダッシュボードをレンダリングし、2 つのフィルターのどちらかをランダムに 5 回変更します。

80%

ダッシュボードをレンダリングし、グラフを選択して、それを 5 回展開したり折りたたんだりします。

10%

ダッシュボードをレンダリングし、グリッドを選択して、それを 5 回展開したり折りたたんだりします。

10%

ユーザーのランダムなフィルター変更やグリッドおよびグラフ上での移動をシミュレートする一連の Web テストおよび負荷テストが、Microsoft Visual Studio 2008 Load Testing ツールを使用して作成されました。この記事で使用したテストでは、操作と操作の間には 15 秒の標準的な一時停止時間 ("待ち時間" とも呼ばれます) が、15 秒の各テスト反復計算間には思考時間が確保されています。また、スコアカードまたはレポートのレンダリングで 2 秒の平均的な応答時間が生成されるように負荷が適用されました。この平均的な応答時間は、10 分間の初期ウォームアップ時間の後、15 分間にわたって測定されました。

新しいテスト反復計算ごとに、5,000 アカウントのプールから個別のユーザー アカウントが選択され、約 2,200 アドレスのプールからランダム IP アドレス (Visual Studio IP 切り替えを使用) が選択されます。

テスト ミックスは、1 つの中規模ダッシュボードに対して 2 回実行されました。最初の実行では、無人サービス アカウントを使用するようにデータ ソース認証が構成されました。この無人サービス アカウントでは、共通のアカウントを使用してデータを要求します。データ結果は複数のユーザーで同じになり、PerformancePoint Services はキャッシュを使用してパフォーマンスを改善します。2 回目の実行では、データ ソース認証はユーザー単位 ID を使用するように構成されました。また、動的なセキュリティを使用するように SQL Server Analysis Services キューブが構成されました。この構成では、PerformancePoint Services はユーザーの ID を使ってデータを要求します。データ結果は異なる可能性があるので、ユーザー間でキャッシュを共有することはできません。ただし、Analysis Services の動的なセキュリティが構成されていない場合、および Microsoft Windows ユーザーとグループが割り当てられている Analysis Services ロールが同じ場合は、ユーザー単位 ID のキャッシュを共有できることがあります。

ハードウェアの設定とトポロジ

ラボのハードウェア

高いレベルのテスト結果詳細を提供できるように、テストでは複数のファーム構成が使用されました。つまり、1 ～ 3 台の Web サーバー、1 ～ 4 台のアプリケーション サーバー、および Microsoft SQL Server 2008 が実行されている 1 台のデータベース サーバーでファームが構成されました。また、SharePoint Server 2010 の既定のエンタープライズ インストールが実行されました。

次の表は、テストで使用されたハードウェアを示しています。

Web サーバー アプリケーション サーバー SQL Server が実行されているコンピューター Analysis Services が実行されているコンピューター

プロセッサ

2px4c @ 2.66 GHz

2px4c @ 2.66 GHz

2px4c @ 2.66 GHz

4px6c @ 2.4 GHz

RAM

16 GB

32 GB

16 GB

64 GB

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

Windows Server 2008 R2 Enterprise

Windows Server 2008 R2 Enterprise

Windows Server 2008 R2 Enterprise

Windows Server 2008 R2 Enterprise

NIC

1x1 ギガビット

1x1 ギガビット

1x1 ギガビット

1x1 ギガビット

認証

NTLM および Kerberos

NTLM および Kerberos

NTLM および Kerberos

NTLM および Kerberos

ファームが複数の Web サーバーにスケール アウトされた後、ハードウェア ロード バランサーが使用され、ソース アドレス アフィニティによってユーザーの負荷が複数の Web サーバーに分散されました。ソース アドレス アフィニティは、受信要求のソース IP アドレスと負荷の分散先サービス ホストを記録し、以降のトランザクションすべてを同じホストに導きます。

トポロジ

開始トポロジは 2 台の物理サーバーで構成されました。1 台目のサーバーは Web およびアプリケーション サーバーとして、2 台目のサーバーはデータベース サーバーとして機能します。この開始トポロジは、2M (2 台のマシン) トポロジ、つまり "1 x 0 x 1" トポロジ (Web 専用サーバー数、アプリケーション専用サーバー数、データベース サーバー数の順) とみなされます。

Web サーバーは、このドキュメントでは Web フロント エンド (WFE) とも呼ばれます。テストでは制限要因が発生するまで負荷が適用されました。通常は、Web サーバーまたはアプリケーション サーバーのどちらかの CPU が制限要因なので、この制限に対処するためにリソースが追加されました。制限要因とトポロジは、無人サービス アカウントまたは動的キューブ セキュリティを備えたユーザー単位 ID のどちらのデータ ソース認証構成が使用されているかによって大きく異なります。

テスト結果

テスト結果には、PerformancePoint Services 容量の定義に役立つ 3 つの重要な測定値が含まれます。

測定 説明

ユーザー数

Visual Studio によってレポートされた総ユーザー数。

秒あたりの要求数 (RPS)

Visual Studio でレポートされた総 RPS 数。すべての要求と、画像、スタイル シートなどの静的ファイル要求が含まれます。

秒あたりのビュー数 (VPS)

PerformancePoint Services がレンダリングできる総ビュー数。ビューは、PerformancePoint Services によってレンダリングされた、または RenderWebPartContent あるいは CreateReportHtml が含まれるレンダリング サービス URL に対する任意の Web 要求によってレンダリングされたフィルター、スコアカード、グリッド、またはグラフです。CreateReportHtml および RenderWebPartContent の詳細については、「PerformancePoint Services RenderingService Protocol Specification (英語)」(https://go.microsoft.com/fwlink/?linkid=200609&clcid=0x411) (英語) を参照してください。

これらの要求に対して IIS ログを解析すると、PerformancePoint Services 容量を計画するのに役立ちます。また、この測定では、ダッシュボード構成への依存度が少ない数値が提供されます。たとえば、2 つのビューを備えたダッシュボードと、10 のビューがあるダッシュボードを比較することができます。

ヒント

無人サービス アカウント認証を使用するように構成されたデータ ソースを使用するとき、専用サーバーの割合の規則は、PerformancePoint Services が実行されている 2 台のアプリケーション サーバーに対して 1 台の Web サーバーです。

ヒント

ユーザー単位の認証を使用するように構成されたデータ ソースを使用するとき、専用サーバーの割合の規則は、PerformancePoint Services が実行されている 4 台以上のアプリケーション サーバーに対して 1 台の Web サーバーです。

4 台のアプリケーション サーバーを超えるトポロジでは、Analysis Services サーバーがボトルネックになる可能性があります。Analysis Services サーバーを複数のサーバーにスケール アウトする必要があるかどうかを判断できるように、Analysis Services の CPU とクエリ時間を監視することを検討してください。Analysis Services サーバーのクエリ時間に遅延が発生すると、PerformancePoint Services の平均応答時間が大幅に増え、望ましいしきい値である 2 秒を超えてしまいます。

次の表は、サーバーを 2 台から 7 台にスケール アウトした場合の無人サービス アカウント認証とユーザー単位の認証の両方のテスト結果の概要を示しています。追加のパフォーマンス カウンターなど、さらに詳しい結果については後で説明します。

無人サービス アカウント認証の概要

トポロジ (WFE x APP x SQL) ユーザー 秒あたりの要求数 (RPS) 秒あたりのビュー数 (VPS)

2M (1x0x1)

360

83

50

3M (1x1x1)

540

127

75

4M (1x2x1)

840

196

117

5M (1x3x1)

950

215

129

6M (2x3x1)

1,250

292

175

7M (2x4x1)

1,500

346

205

ユーザー単位の認証の概要

トポロジ (WFE x APP x SQL) ユーザー 秒あたりの要求数 (RPS) 秒あたりのビュー数 (VPS)

2M (1x0x1)

200

47

27

3M (1x1x1)

240

56

33

4M (1x2x1)

300

67

40

5M (1x3x1)

325

74

44

2M および 3M トポロジ

トランザクションあたりのハードウェア コストと応答時間曲線について説明するために、2M および 3M トポロジに対して、ユーザー負荷を 4 段階で最大になるまで増やしながら負荷テストを実行しました。

無人サービス アカウント認証

ユーザー数 50 150 250 360

平均 WFE/APP CPU

19.20%

57.70%

94.00%

96.70%

RPS

18

53

83

83

秒あたりのビュー数

10.73

31.72

49.27

49.67

平均応答時間 (秒)

0.12

0.15

0.38

2

PPS_CapicityChart1

ユーザー単位の認証

ユーザー数 50 100 150 200

平均 WFE/APP CPU

30.80%

61.30%

86.50%

93.30%

RPS

17

32

43

47

秒あたりのビュー数

10.3

19.32

26.04

27.75

平均応答時間 (秒)

0.28

0.45

0.81

2

PPS_CapicityChart2

3M (1x1x1) ファームの結果

無人サービス アカウント認証

ユーザー数 100 250 400 540

RPS

36

87

124

127

秒あたりのビュー数

21

52

74

75

平均応答時間 (秒)

0.12

0.18

0.65

2

平均 WFE CPU

11%

28%

43%

46%

SharePoint Server インターネット インフォメーション サービス (IIS) ワーカー プロセス W3WP の WFE プライベート バイトの最大サイズ

0.7 GB

1.4 GB

2.0 GB

2.4 GB

平均 APP CPU

25%

62%

94%

95%

PerformancePoint Services W3WP の APP プライベート バイトの最大サイズ

10.8 GB

10.8 GB

14.1 GB

14.6 GB

PPS_CapicityChart3

ユーザー単位の認証

ユーザー数 50 120 180 240

RPS

17

39

52

56

秒あたりのビュー数

10

23

31

33

平均応答時間 (秒)

0.28

0.48

0.91

2

平均 WFE CPU

5%

12%

17%

19%

SharePoint Server W3WP の WFE プライベート バイトの最大サイズ

0.78 GB

1.3 GB

1.6 GB

1.9 GB

平均 APP CPU

25%

57%

81%

81%

PerformancePoint Services W3WP の APP プライベート バイトの最大サイズ

19 GB

20.1 GB

20.5 GB

20.9 GB

PPS_CapicityChart4

4M 以上の結果 (無人サービス アカウント認証)

4M トポロジからは、スコアカードまたはレポートのレンダリングで 2 秒間の平均的な応答時間が生成されるように負荷が適用されました。次に、サーバーを追加することで制限要因 (通常は、Web サーバーまたはアプリケーション サーバーの CPU) を解決し、テスト ミックスを再実行しました。このロジックは、総サーバー数が 7 台になるまで繰り返されました。

4M (1x2x1) 5M (1x3x1) 6M (2x3x1) 7M (2x4x1)

ユーザー数

840

950

1,250

1,500

RPS

196

216

292

346

秒あたりのビュー数

117

131

175

206

平均 WFE CPU

77%

63%

54%

73%

SharePoint Server W3WP の WFE プライベート バイトの最大サイズ

2.1 GB

1.7 GB

2.1 GB

2.0 GB

平均 APP CPU

83%

94%

88%

80%

PerformancePoint Services W3WP の APP プライベート バイトの最大サイズ

16 GB

12 GB

15 GB

15 GB

4M 以上の結果 (ユーザー単位の認証)

ユーザー単位の認証用に構成されたデータ ソースに対しても、同じテストを実行しました。アプリケーション サーバーを追加して 4 台のアプリケーション サーバー トポロジを作成しても、Analysis Services によってクエリ遅延が発生するので、PerformancePoint Services がサポートするユーザー数または秒あたりの要求数が増えていないことに注意してください。

3M (1x1x1) 4M (1x2x1) 5M (1x3x1) 6M (1x4x1)

ユーザー数

240

300

325

325

RPS

56

67

74

74

秒あたりのビュー数

33

40

44

45

平均 WFE CPU

19%

24%

26%

12%

SharePoint Server W3WP の WFE プライベート バイトの最大サイズ

2.1 GB

1.9 GB

1.9 GB

1.5 GB

平均 APP CPU

89%

68%

53%

53%

PerformancePoint Services W3WP の APP プライベート バイトの最大サイズ

20 GB

20 GB

20 GB

20 GB

Analysis Services CPU

17%

44%

57%

68%

PPS_CapicityChart5

推奨事項

ハードウェアに関する推奨事項

テストの表のメモリおよびプロセッサのカウンターを使用して、PerformancePoint Services インストールのハードウェア要件を確認してください。Web サーバーについては、PerformancePoint Services では、推奨 SharePoint Server 2010 ハードウェア要件を使用します。アプリケーション サーバーのハードウェア要件については、PerformancePoint Services が大量のメモリを消費する場合は変更しなければならないことがあります。これは、データ ソースがユーザー単位の認証に対して構成されている場合、またはアプリケーション サーバーが多数のダッシュボードを実行していることでデータ ソースのタイムアウト時間が長くなっている場合に発生します。

データベース サーバーはテストではボトルネックにはならず、7M 無人サービス アカウント認証されたダッシュボードでは、CPU 最大使用率である 31% に達しました。レポート、スコアカード、KPI などの PerformancePoint Services コンテンツ定義は SharePoint リストに格納され、PerformancePoint Services によってメモリにキャッシュされるので、データベース サーバーに対する負荷が軽減されます。

メモリ消費

構成によっては PerformancePoint Services では大量のメモリが消費される場合があります。したがって、PerformancePoint Services アプリケーション プールのメモリ使用量を監視することが重要です。PerformancePoint Services では、Analysis Services、その他のデータ ソースのクエリ結果など、複数のアイテムがデータ ソースのキャッシュの有効期間 (既定では 10 分間) だけメモリにキャッシュされます。無人サービス アカウント認証に対して構成されたデータ ソースを使用する場合、このクエリ結果が格納されるのは 1 回だけで、複数のユーザーによって共有されます。一方、ユーザー単位の認証および Analysis Services の動的キューブ セキュリティに対して構成されたデータ ソースを使用する場合は、クエリ結果は、1 ビュー 1 ユーザー (つまり、"1 フィルター") ごとに 1 回格納されます。

PerformancePoint Services が使用する基になるキャッシュ API は ASP.NET Cache API です。この API を使用する大きなメリットは、ASP.NET がキャッシュを管理し、メモリ制限に基づいてアイテムを削除 (トリミングとも呼ばれます) するので、メモリ不足エラーを回避できるという点です。既定のメモリ制限は物理メモリの 60 パーセントです。この制限に達しても、PerformancePoint Services ではビューがレンダリングされますが、キャッシュされたエントリを ASP.NET が削除するとき応答時間が一時的にかなり長くなります。

PerformancePoint Services をホストするアプリケーション プールのパフォーマンス カウンター "ASP.NET Applications \ Cache API Trims" を使用すると、メモリ使用率が原因で発生する ASP.NET キャッシュ トリミングを監視できます。このカウンターがゼロよりも大きい場合は、次の表で考えられる解決策を確認してください。

問題 解決策

アプリケーション サーバー プロセッサの使用率が低く、アプリケーション サーバーで他のサービスが実行されている。

物理メモリを追加するか、ASP.NET キャッシュのメモリを制限します。

アプリケーション サーバー プロセッサの使用率が低く、アプリケーション サーバーで PerformancePoint Services のみが実行されている。

可能であれば、キャッシュがより多くのメモリを使用するように ASP.NET キャッシュ設定を構成するか、メモリを増やします。

アプリケーション サーバー プロセッサの使用率が高い。

他のアプリケーション サーバーを追加します。

ユーザーの Analysis Services ロール メンバーシップ セットが同じで、動的キューブ セキュリティが構成されていない場合、ユーザー単位の認証を使用するように構成されているデータ ソースはクエリ結果とキャッシュ エントリを共有できます。これは、Microsoft SharePoint Server 2010 の PerformancePoint Services を対象とした新しい機能です。たとえば、ユーザー A とユーザー B がロール 1 と 2 に所属し、ユーザー C がロール 1、2、および 3 に属している場合は、ユーザー A とユーザー B のみがキャッシュ エントリを共有できます。また、動的キューブ セキュリティが構成されている場合は、ユーザー A、ユーザー B 、ユーザー C の誰もキャッシュ エントリを共有できません。

Analysis Services

PerformancePoint Services がユーザー単位の認証でテストされたときに、複数ユーザー スループットのパフォーマンスが向上するように 2 つの Analysis Services プロパティが変更されました。次の表は、変更されたプロパティと各プロパティの新しい値を示しています。

Analysis Services プロパティ 値

Memory \ HeapTypeForObjects

0

Memory \ MemoryHeapType

2

この 2 つのメモリ設定では、Analysis Services ヒープではなく Windows ヒープを使用するように Analysis Services が構成されます。このプロパティを変更する前は、通常は 0.2 秒の応答時間が、ユーザー負荷が追加されている間は 30 秒を超えるまでに長くなりました。一方、Web、アプリケーション、および Analysis Services サーバーの CPU は低いままでした。この問題を解決するために、Analysis Services 動的管理ビュー (DMV) を使用してクエリ時間が収集されました。この DMV は、個別のクエリ時間が 10 ミリ秒から 5,000 ミリ秒に増えていることを示していたので、上記のようにメモリ設定を変更することにしました。

このようにスループットは大幅に向上しましたが、Analysis Services チームからは、この設定変更による 1 人のユーザーのクエリに対するコストは、小さいけれども決して無視できないものであることが報告されています。

Analysis Services プロパティを変更する前に、「SQL Server 2008 ホワイト ペーパー: Analysis Services パフォーマンス ガイド」(https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x411) を参照し、複数ユーザー スループットのパフォーマンス向上のベスト プラクティスについて参照してください。

一般的なボトルネックとその原因

パフォーマンスのテスト中、一般的なボトルネックがいくつかわかってきました。ボトルネックとは、特定のファーム構成の容量が限界に達している状態のことをいい、これによりファームのスループットが停滞または低下します。プロセッサの使用率が高いことがボトルネックになっている場合は、サーバーを追加することで、そのボトルネックを解消します。次の表は、一般的なボトルネックと考えられる解決策を示しています。なお、ここではプロセッサの使用率は低く、ボトルネックにはなっていないものとします。

考えられるボトルネック 原因と監視対象 解決方法

Analysis Services メモリ ヒープのパフォーマンス

Analysis Services では Windows ヒープではなく独自のメモリ ヒープが既定で使用されるので、複数ユーザー スループットのパフォーマンスが低下します。動的管理ビュー (DMV) を使用して Analysis Services のクエリ時間を確認し、ユーザー負荷によってクエリ時間が長くなっていないか、また Analysis Services プロセッサの使用率が低くなっていないかを確かめます。

Windows ヒープを使用するように Analysis Services を変更します。手順については、この記事の「Analysis Services」セクション、および「SQL Server 2008 ホワイト ペーパー: Analysis Services パフォーマンス ガイド」(https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x411) を参照してください。

Analysis Services クエリおよび処理スレッド

Analysis Services では、クエリ数とクエリの処理スレッドが既定で制限されています。クエリが長時間実行されている場合やユーザー負荷が高い場合は、使用可能なすべてのスレッドが使用されることがあります。MSAS 2008:Threads カテゴリの使用されていないスレッドおよびジョブ キューのパフォーマンス カウンターを監視します。

クエリおよび処理で使用できるスレッドの数を増やします。手順については、「SQL Server 2008 ホワイト ペーパー: Analysis Services パフォーマンス ガイド」(https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x411) の「Analysis Services」セクションを参照してください。

アプリケーション サーバーのメモリ

PerformancePoint Services では、Analysis Services およびその他のデータ ソースのクエリ結果が、データ ソースのキャッシュの有効期間だけメモリにキャッシュされます。これらのアイテムは大量のメモリを消費することがあります。PerformancePoint Services アプリケーション プールの ASP.NET Applications \ Cache API Trims を監視して、メモリ不足が原因で ASP.NET によってキャッシュ削除 (トリミング) が強制的に行われていないかどうかを確認します。

メモリを追加するか、既定の ASP.NET キャッシュ メモリ制限を増やします。詳細については、このドキュメントの「メモリ消費」セクションを参照してください。また、「ASP.NET キャッシュ要素の設定」(https://go.microsoft.com/fwlink/?linkid=200610&clcid=0x411) および「Some history on the ASP.NET cache memory limits (英語)」(https://go.microsoft.com/fwlink/?linkid=200611&clcid=0x411) (英語) の Thomas Marquardt 氏のブログの投稿を参照してください。

WCF 調整の設定

PerformancePoint Services は WCF サービスとして実装されます。WCF では、同時呼び出しの最大数がサービス調整の動作として制限されます。このボトルネックは、クエリが長時間実行されている場合に発生する可能性がありますが、めったに発生しません。PerformancePoint Services の完了していない WCF / Service Model パフォーマンス カウンター呼び出しを監視し、同時呼び出しの現在の最大数と比較してください。

必要に応じて、Windows Communication Foundation (WCF) 調整動作を変更します。「WCF サービス調整の動作」(https://go.microsoft.com/fwlink/?linkid=200612&clcid=0x411) および「WCF Request Throttling and Server Scalability (英語)」(https://go.microsoft.com/fwlink/?linkid=200613&clcid=0x411) (英語) の Wenlong Dong 氏のブログの投稿を参照してください。

パフォーマンスの監視

システムをスケール アップまたはスケール アウトするタイミングを判断するには、パフォーマンス カウンターを使用してシステムの正常性を監視します。PerformancePoint Services は ASP.NET WCF サービスなので、他の ASP.NET WCF サービスを監視するときに使用するパフォーマンス カウンターを使用して監視できます。さらに、次の表の情報を使用して、監視する補助パフォーマンス カウンターと、そのパフォーマンス カウンターが適用されるプロセスを判断します。

パフォーマンス カウンター カウンター インスタンス メモ

ASP.NET Applications / Cache API Trims

PerformancePoint Services アプリケーション プール

値がゼロよりも大きい場合は、「メモリ消費」を参照してください。

MSAS 2008:Threads / Query pool idle threads

該当なし

値がゼロの場合は、「SQL Server 2008 ホワイト ペーパー: Analysis Services パフォーマンス ガイド」(https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x411) の「Analysis Services」セクションを参照してください。

MSAS 2008:Threads / Query pool job queue length

該当なし

値がゼロより大きい場合は、SQL Server 2008 ホワイト ペーパー: Analysis Services パフォーマンス ガイド」(https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x411) の「Analysis Services」セクションを参照してください。

MSAS 2008:Threads / Processing pool idle threads

該当なし

値がゼロより大きい場合は、SQL Server 2008 ホワイト ペーパー: Analysis Services パフォーマンス ガイド」(https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x411) の「Analysis Services」セクションを参照してください。

MSAS 2008:Threads / Processing pool job queue length

該当なし

値がゼロより大きい場合は、SQL Server 2008 ホワイト ペーパー: Analysis Services パフォーマンス ガイド」(https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x411) の「Analysis Services」セクションを参照してください。

WCF CountersServiceModelService 3.0.0.0(*)\Calls Outstanding

PerformancePoint Service インスタンス

値がゼロより大きい場合は、「WCF Request Throttling and Server Scalability (英語)」(https://go.microsoft.com/fwlink/?linkid=200613&clcid=0x411) (英語) を参照してください。

See Also

Concepts

PerformancePoint Services を計画する (SharePoint Server 2010)