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 サンプル データベースが使用されました。

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

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

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

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

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

ユーザーのランダムなフィルター変更やグリッドおよびグラフ上での移動をシミュレートする一連の 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 サーバーにスケール アウトされた後、ハードウェア ロード バランサーが使用され、ソース アドレス アフィニティによってユーザーの負荷が複数の Web サーバーに分散されました。ソース アドレス アフィニティは、受信要求のソース IP アドレスと負荷の分散先サービス ホストを記録し、以降のトランザクションすべてを同じホストに導きます。

トポロジ

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

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

テスト結果

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

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

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

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

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

2M および 3M トポロジ

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

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

ユーザー単位の認証

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

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

ユーザー単位の認証

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

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

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

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

推奨事項

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

テストの表のメモリおよびプロセッサのカウンターを使用して、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 キャッシュ トリミングを監視できます。このカウンターがゼロよりも大きい場合は、次の表で考えられる解決策を確認してください。

ユーザーの 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 プロパティが変更されました。次の表は、変更されたプロパティと各プロパティの新しい値を示しています。

この 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) を参照し、複数ユーザー スループットのパフォーマンス向上のベスト プラクティスについて参照してください。

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

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

パフォーマンスの監視

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

See Also

Concepts

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