当社ではユニットテストを行っています。開発者と自動ビルドの両方がそれらを実行できるように、テスト スイートの一部にもなる自動パフォーマンス テストを作成することを考えています。テストは何かを実行し、事前に見積もった時間よりも長くかかった場合は失敗します。
問題は、コンピューターによって CPU 速度が異なり、バックグラウンドで実行されているプロセスによって実行速度が遅くなる可能性があることです。では、これらのテストをどのように行うべきでしょうか?
5 に答える
2
1つの戦略は、コードが実行される最適なマシンのパフォーマンスメトリックを設計することです。劣悪なマシンで十分に高速に動作する限り、本番環境でのパフォーマンスが向上することが保証されます。基本的に、おそらくテスト/開発中に、低速のマシンで実行する必要があることを知っているファッジファクターを含めます。
もう1つの戦略は、テストセットアップ中にベンチマークを実行し、その時間量を秒ではなく「単位時間」として使用することです。たとえば、dog-slow再帰アルゴリズムを使用して20番目のフィボナッチ数を計算し、すべてのテストを10 "20-fibs"以内で実行する必要があると言うと、低速のマシンでは実時間が遅くなりますが、あなたはそれがどれだけうまく動いているかについての機械に依存しない測定基準を持っています。
バックグラウンドで実行されているプロセスはより困難です。明らかに、通常は他のものがテストに干渉することを望まないため、1つの戦略は、それを可能な限り排除することです。通常の開発者は、失敗した場合に一部のプロセスを強制終了して再実行できます。継続的インテグレーションボックスは次のようになります。比較的明確に保たれました。
それが機能しない場合、または十分でない場合は、反対のアプローチを試すことができます。テストと同時にCPU / IOを集中的に使用するプロセスを実行して、過負荷のシステムを模倣し、テストに合格した場合環境では、パフォーマンスは通常のシステムで良好である必要があります
于 2011-11-29T16:07:22.150 に答える
1
コードの変更がパフォーマンスにどのように影響するかを理解し、パフォーマンスが以前のビルド以上であることを確認することが目的の場合は、既知のハードウェアプロファイルで毎回テストを実行する必要があります。これを行う最も正確な方法は、テストが実行されるたびにテストに使用するマシンをセットアップすることです。多くの開発者がこれを、時には同時に行う必要がある場合は、スピンアップしてテストを実行するためにポイントできるVMイメージを作成することは価値があります。
前述のように、あらゆる種類の要因がこれらのボックスのテスト結果に影響を与える可能性があるため、開発者ボックス自体でこれらを実行しないでください。
テストケースの一部として特別に設定されていない限り、テスト対象のシステムの外部から負荷/負荷がかかっているときにパフォーマンスを測定しようとしないでください（ディスク容量、ネットワーク帯域幅、メモリ、CPUなど）。たとえば、3つの異なるテストを実行できます。1つはマシンに負荷がかかっていないとき、もう1つは中負荷（バックグラウンドで実行されている他のプログラムをシミュレート）、もう1つは高負荷です。
他のストレス/パフォーマンステストの一部としてさまざまなハードウェアプロファイルでテストを実行することもできますが、すべてのビルドに対してそれらを実行しても、おそらく多くの価値は得られません。ただし、ここでも、異なるハードウェアプロファイルに対していくつかの異なるテストを実行できるようにする場合は、追加のマシンやVMイメージのセットアップ、およびこれらのマシンに対するテストを開始するためのインフラストラクチャが必要になるため、より多くのセットアップが必要になります。結果を収集し、それらについて報告します。
于 2011-11-29T22:40:32.423 に答える
1
サムの応答に+1。私は過去に何度もこれを行ってきましたが、パフォーマンス テスト環境をロックダウンし、潜在的な変化を最小限に抑えることが重要です。
開発者のシステムでテストを実行することは、個々の開発者にとって有用なフラグになる可能性がありますが、テストを実行するための中央システムを持つことは重要です。VM でこれを行う場合の注意点として、VM ホスト システムの負荷がホストされている VMのパフォーマンスに影響を与える可能性があるため、VMホストシステムの負荷を理解しておく必要があります。
毎晩のスモーク チェック ビルド中にこの種のスイートを実行したとき、最高の、最も一貫性のある、有用な結果が得られました。
于 2011-11-30T18:42:41.270 に答える
1
プログラムの制限リソース (I/O、CPU、メモリ) に応じて、使用された CPU 時間を測定し、それをシステム速度と比較すると、良い結果が得られます。たとえば、現在のプログラムのパフォーマンス テストでは、消費された CPU 時間をtime取得し、CPU 速度を取得し/proc/cpuinfoて、計算に費やされたサイクル数を測定します。
このアプローチには 2 つの注意点があります。1 つ目は、達成された並列性を測定しないこと、2 つ目は、I/O 使用率などの外部パフォーマンス要因を測定しないことです。
于 2011-11-29T16:14:39.100 に答える
0
また、テストを有効にする公差 (または許容可能な容量範囲) についての質問でもあります。前述のように、理想的には、有効な比較のために、予測可能で安定した一貫したセットアップが必要です。つまり、SUT の基本的な動作範囲 (使用可能な CPU、使用可能なメモリなど) を理解していれば、既知のリソース許容範囲内にあるシステムと条件を組み合わせて、初期の開発者テストを実行できます。
于 2013-03-29T15:59:05.620 に答える