パフォーマンステストを追跡する方法

Question

現在、さまざまな変更の影響を調査する複雑な多階層システムのパフォーマンスと負荷テストを行っていますが、すべてを追跡するのに問題があります：

• さまざまなアセンブリのコピーが多数あります
  • 最初にリリースされたアセンブリ
  • 公式にリリースされたホットフィックス
  • 追加の修正を含む、私が構築したアセンブリ
  • 追加の診断ログまたはトレースを含むビルドしたアセンブリ
• 多くのデータベースパッチがあります。上記のアセンブリの一部は、適用されている特定のデータベースパッチに依存しています
• 多くの異なるログレベルが存在します、異なる層（アプリケーションログ、アプリケーションパフォーマンス統計、SQLサーバープロファイリング）
• さまざまなシナリオがあります。1つのシナリオのみをテストすると便利な場合もあれば、さまざまなシナリオの組み合わせをテストする必要がある場合もあります。
• 負荷は複数のマシンに分割される可能性がありますまたは単一のマシンのみ
• データベースに存在するデータは変更される可能性があります。たとえば、生成されたデータを使用していくつかのテストを実行し、その後ライブシステムから取得したデータを使用して実行できます。
• 各テスト後に収集される膨大な量の潜在的なパフォーマンスデータがあります。例：
  • さまざまな種類のアプリケーション固有のロギング
  • SQLプロファイラートレース
  • イベントログ
  • DMV
  • パフォーマンスカウンター
• データベースのサイズは数Gbです。バックアップを使用して以前の状態に戻す場合、最後のテスト後に存在するデータベースに変更を適用する傾向があり、すぐに物事の追跡を失います。

私は、各テスト（テストされたシナリオ、どのパッチがデータベースにあるデータに適用されているか）についてできる限り多くの情報を収集しますが、一貫性のない結果のためにテストを繰り返さなければなりません。たとえば、数か月前に実行したテストの正確な複製と思われるテストを実行しましたが、データベースのデータは更新されています。新しいデータがパフォーマンスの偏りを引き起こすはずであるという事実は知っていますが、結果は逆になります！

同時に、これらすべての詳細を記録するのに不均衡な時間を費やしていることに気づきました。

私が検討したことの1つは、パフォーマンスデータなどの収集を自動化するためにスクリプトを使用することでした...物事の追跡がさらに速くなる可能性があります。

テスト環境の管理方法、特にすべてを収集することと、重要な何かを見落とすリスクのあるテストを実際に行う方法とのバランスをとる方法に関するアドバイス/ヒント

Answer 1

テストパラメータと環境のコレクションをスクリプト化することは、チェックアウトすることをお勧めします。数日間にわたってテストを行っており、スクリプトの作成に1日かかる場合は、時間がかかります。 1日たってもすぐに終わらない場合は、再評価し、この方向の追跡を停止してください。

ただし、試してみるのはあなた自身です。

Answer 2

@oripには同意する傾向があります。ワークロードの少なくとも一部をスクリプト化すると、時間を節約できる可能性があります。少し時間をかけて、どのタスクがあなたの労働の面で最も時間を消費しているのか、そしてそれらのタスクが自動化にどの程度従いやすいのかを尋ねることを検討するかもしれません。スクリプトは、データの収集と要約に特に優れており、通常は人よりもはるかに優れています。パフォーマンスデータで多くの解釈が必要な場合、問題が発生する可能性があります。

これらのタスクの一部をスクリプト化することの利点は、ソース/パッチ/ブランチと一緒にチェックインできることです。システムの複雑さの組織構造は、今のように追いかけるのに苦労するのではなく、恩恵を受けることがあります。

Answer 3

管理者をシンプルにする少数の設定構成に対してのみテストを行うことができる場合。また、クリーンなベースラインを提供するために迅速に再デプロイできる複数の仮想マシンのそれぞれに1つずつ配置するのが簡単になる場合があります。

説明する複雑さが本当に必要な場合は、単純なデータベースを作成して、多変量の結果を照会できるようにすることをお勧めします。重要な要素ごとに列を用意することで、「どのテスト構成で待ち時間の変動が最も少ないか」などの質問を照会できます。および「ほとんどのバグの発生を許可したテストデータベースはどれですか？」この種類の軽量コレクションにはsqlite3（おそらくPythonラッパーまたはFirefoxプラグインを使用）を使用します。これは、メンテナンスのオーバーヘッドを比較的低く抑え、実行する必要がある場合でもテスト中のシステムの混乱を避けることができるためです。同じ箱。

テストのスクリプトを作成すると、テストの実行が速くなり、順序付けられた方法で結果を収集できますが、システムが複雑すぎて簡単に実行できないようです。