相対的なパフォーマンスの単位テストはどのようにして行いますか？

Question

デプロイ時に私のコードがどのようなシステムで実行されるのか分からないので、システムの可能性をその基準として使うパフォーマンスベンチマークを書くにはどうすればいいですか？

私が意味することは、システムが1秒間に1000回のコードを実行できるならば、テストができるだけ1000に近いことを確認したいと思います。それが500しかできないなら、それは私がそれを比較したいと思う率です。

答えをより具体的にする場合は、JUnit4を使用しています。

ありがとうございます。

Answer 1

テスト

はあなたが合格/不合格のしきい値を持っていることを意味します。パフォーマンステストでは、これは遅すぎるということを意味し、失敗した場合、十分に速く、パスします。失敗した場合は、再作業を開始します。

あなたが失敗することができなければ、実際にテストしていないベンチマークです。

「システムは実行可能です」と話すときは、「有能」を定義する必要があります。多数のハードウェアパフォーマンスベンチマークのいずれかを使用できます。砥石、Dhrystoneなどが人気があります。また、データベースを大量に使用するアプリケーションがある場合は、TPCベンチマークを参照することもできます。または、おそらくネットワークを大量に使用するアプリケーションがあり、netperfを使いたいと思うかもしれません。またはGUIを大量に使用するアプリケーションで、何らかのグラフィックスベンチマークを使用したい場合。

これらのいずれも、ある種の「機能」測定値を示します。 1つ以上を選んでください。彼らはすべて良いです。同様に議論の余地がある。同じようにあなたの競争相手に向かって偏って、あなたから離れています。

ベンチマークを実行したら、ソフトウェアを実行してシステムが実際に何をするかを確認できます。

十分なデータを収集すれば、いくつかのベンチマーク番号とパフォーマンス番号との間に相関関係を確立することができます。

十分な数の異なる構成の十分なデータがあれば、最終的にパフォーマンスを開発することができます「このハードウェア、ソフトウェア、チューニングのパラメータと設定を考慮すると、私のソフトウェアは毎秒[X]件のトランザクションを実行すると期待しています」というモデルです。それは「有能」の堅実な定義です。

このモデルを取得したら、ソフトウェアと機能番号を比較できます。非常に完全なモデルが得られるまで、どのシステムがコードを1秒間に1000回実行することさえできるのかは本当に分かりません。

Answer 2

パフォーマンステストでは、いくつかの理由からユニットテストを使用しません。

最初に、単体テストは周囲のシステム/コードに依存してはいけません。性能テストはハードウェア/ OSに大きく依存するため、デベロッパーワークステーション、サーバー構築などの両方で使用できる統一された手段を得ることは難しいです。

第2に、単体テストは本当に高速で実行する必要があります。パフォーマンステストを行うときは、通常、非常に大きなデータセットを持ち、数を平均して数を増やしたり、オーバーヘッドをなくすなど、実行回数を2回繰り返すことが必要です。これらはすべて高速テストのアイデアに反するものです。

Answer 3

私は、計算に時間がかかりすぎた正解が失敗したリアルタイムシステム向けのコードのテストで時間を測定しています。

私が行っているのは、テストが最近のビルドを引き継いだデルタCPU時間をプロットしたものです。 CPU時間はリアルタイムではありません。実際の価値はそれほど重要ではありません。何が変わったかが重要です。

テストの実行時間を大幅に変更したアルゴリズムを変更した場合、それを引き起こした特定のチェンジセットに容易にズームインできます。私が本当に気にしているのは、これらの興味深い点です。必ずしも絶対値ではありません。リアルタイムシステムにはしばしば多くのトレードオフがあり、これらを単純な比較としてテストフレームワークに常に表現することはできません。

絶対時間を見て最初に正規化するのは合理的ですが、実際にはシステムとターゲットシステムの間の変換は非線形になります。例えば、キャッシュの圧力、スワップの使用、ターゲットシステムのディスク速度などテストがシステムと異なるしきい値で爆発する時間。私の場合は

あなたは絶対にターゲットシステムを複製し、あなたはそれがであることを期待した試験奴隷としてではなく似た環境でそれを使用して、この点で正確であるテストが必要な場合。

それがかもしれません実際にDSPにファームウェアをダウンロードしたり、リモートで電源を切ったり、シリアルポートからの応答を読み込んだり、クラッシュしたため応答が見られません。 --jeffk ++

Answer 4

ユニットテストは、パフォーマンステストを行う適切な方法ではないと言いますと、私はBrianに同意します。しかし、異なるシステム構成/環境で実行するためのの統合テストとして使用できる短い例をまとめました。
これは、この点で何ができるのかを知るだけで、システムのパフォーマンスに関する正式な記述をバックアップするのに十分正確な結果は得られません。

import static org.junit.Assert.*; 
import org.junit.Test; 

package com.stackoverflow.samples.tests { 

    @Test 
    public void doStuffRuns500TimesPerSecond() { 
     long maximumRunningTime = 1000; 
     long currentRunningTime = 0; 
     int iterations = 0; 

     do { 
      long startTime = System.getTimeMillis(); 

      // do stuff 

      currentRunningTime += System.getTimeMillis() - startTime; 
      iterations++; 
     } 
     while (currentRunningTime <= maximumRunningTime); 

     assertEquals(500, iterations); 
    } 
}