Team Foundation Server のパフォーマンスの評価
更新 : 2007 年 11 月
パフォーマンス カウンタと監視ツールを構成して、Team Foundation Server のパフォーマンスを評価できます。このデータを時間と共に検討および解析することで、Team Foundation Server 配置全体のパフォーマンスを評価できます。また、パフォーマンス データの検討は、問題を特定して解決するのにも役立ちます。
Team Foundation Server 自体は、SQL Server を使用してデータを格納する ASP.NET SQL Server アプリケーションです。この種のアプリケーションの監視に慣れている場合は、同じ方法を使用して Team Foundation Server を監視し、そのパフォーマンスを評価できます。
ベースラインの確立
Team Foundation Server 配置はそれぞれ異なっています。Team Foundation Server のパフォーマンスには、ハードウェア、ソフトウェア、ユーザー数、プロジェクト数、各プロジェクトで使用されるプロセス テンプレート、およびソース データと作業項目の量の違いがすべて影響します。特定の Team Foundation Server 配置について、ベースラインのパフォーマンス データを確立しておくことが重要です。このデータによって、パフォーマンスに大きな変化が生じた場合に変化を識別できます。また、時間の経過と共に、Team Foundation Server ハードウェアの全体的なパフォーマンス要求をより正確に把握できます。
Team Foundation Server のインフラストラクチャは非常に広範囲です。監視する対象や、検出された値に対するアクションが必要かどうかを判断する方法を事前に決定する必要があります。たとえば、80% 以上の CPU 使用率が 10 分以上続いた場合はアクションを実行するように決定できます。この決定を文書化し、定義済みのしきい値がプロジェクトの他のメンバにわかるようにすることができます。このような変数と状態をすべて 1 箇所に集めると、Team Foundation Server の環境の正常性を表す状態について文書化した情報モデルができます。この戦略は、正常性モデルまたは正常性情報とも呼ばれます。正常性モデルは、システムの状態を定義する観察可能な状態の集まりです。前の例では、CPU 使用率を監視する際のしきい値を定義しています。この例に示されているように、正常性モデルは科学や数学よりも規約や合意の問題です。
Team Foundation Server の管理者は、監視する対象と、しきい値を基準点として状態が変化したかどうかを評価する方法を決定する必要があります。正常性モデルがない場合は、配置の正常性を測定できる基準点がないことになります。
ベースラインを確立するためのツール
パフォーマンスの監視は、ログの監視とは大きく異なります。パフォーマンスの監視では、特定のパフォーマンス カウンタのセットを特定の期間中、観察する必要があります。たとえば、応答時間に関する懸念に対処するためにパフォーマンスを監視することができます。通常のダウンロード時間に関するデータがないと、特定のプロジェクトのソース ツリーをダウンロードするときの応答時間について、ユーザーの苦情に対応することは困難です。Team Foundation Server には、サーバーのパフォーマンスを監視するための特別なツール セットは用意されていませんが、Windows Server 2003、Microsoft SQL Server 2005、および .NET Framework の監視ツールやオプションを使用して、Team Foundation Server 配置を監視できます。また、Team Foundation Server のパフォーマンスを監視する独自のツールを作成することもできます。詳細については、「Team Foundation Server の監視ツールについて」を参照してください。
データの評価
ログ記録データ、トレース データ、パフォーマンス監視データ、およびサービス監視データはすべて、理解および解釈するために異なるアプローチが必要です。最初に、何かが発生したかどうかを把握し、検証する必要があります。次に、必要に応じて、システムを正常な状態に戻すためのアクションを決定する必要があります。この情報の把握とアクションの決定は、配置ごとに独自のプロセスです。ただし、すべてのプロセスには時間の経過を伴う集中的な作業が必要です。配置を監視して収集したデータと、望ましくない変化に対応するために実行したアクションの記録を残しておくと、カスタマイズした独自の応答情報を簡単に開発できます。市販のソフトウェア スイートに投資して、このデータの収集と保存を自動化することもできます。
Team Foundation Server 配置のベースラインを確立すると、Team Foundation Server 全体の状態を適切に判断できるようになります。たとえば、イベント ビューアに実行時のデータベース例外が定期的に記録される場合は、Team Foundation データ層サーバーのプロセッサまたはメモリ リソースが不足している可能性があります。同様に、Team Foundation Server のパフォーマンス カウンタの 1 つが突然低下を示す場合は、Team Foundation アプリケーション層サーバー全体のパフォーマンスに加えて、問題のパフォーマンス カウンタに対応するアプリケーションを調べる必要があります。詳細については、「パフォーマンスの監視」を参照してください。
バージョン管理のパフォーマンスの監視
バージョン管理とチーム ビルド環境を監視する場合、多くの変数を扱う必要があります。開発サイクルに関する十分な知識がある場合は、バージョン管理で何を注意深く監視する必要があるかを、より正確に予測できます。さらに、それらの制限がわかっている場合は、問題に事前に対応できます。
Team Foundation Server には、バージョン管理を監視するための多数のパフォーマンス カウンタがあります。次の表に示すカウンタを目的に応じて使用できます。すべてのカウンタの一覧については、「パフォーマンスの監視」を参照してください。
Team Foundation ビルドのパフォーマンスの監視
どのツールセットでも同じように、配置によって定義される用途は大きく異なります。たとえば、単一のビルド環境で単一のビルド スクリプトを使用するプロジェクトは、複数のビルド環境で複数のビルド スクリプトを使用するチーム プロジェクトとは用途が大きく異なります。Team Foundation ビルドのパフォーマンスを効率的に監視するには、配置のニーズに適した監視基準を決定する必要があります。Team Foundation ビルドで監視が必要になる可能性のある項目を次に示します。
ビルドの平均実行時間
ビルド実行回数
たとえば、デイリー ビルドは 1 日に 1 回だけ発生する必要があります。
特定のタイム フレーム内に発生したビルド失敗の回数
営業時間外に発生したビルドの回数
Team Foundation ビルドを実行しているサーバーの標準パフォーマンス基準
たとえば、CPU 使用率を監視できます。
実行時間の長いビルドの平均実行時間
正常に終了したビルドの通知
Team Foundation ビルド環境で重要な要因を判断するのに役立つツールと手順を次に示します。
Team Foundation ビルドの概要を表示すると、エラーを識別し、ビルド完了までの所要時間を確認できます。詳細については、「方法 : ビルド概要ステータスを表示する」を参照してください。
ビルドの進行状況を監視することによって、どの手順または項目が原因でビルド完了までの所要時間が予想よりも長くなっているのかを判断できます。詳細については、「方法 : ビルドの進行状況を監視する」を参照してください。
ビルド通知を受信することによって、現在のビルドの状態を確認できます。詳細については、「方法 : ビルドの通知の電子メールを受け取る」を参照してください。
参照
概念
Team Foundation Server の監視ツールについて