3

展開時にコードが実行されるシステムの種類がわからない場合、システムの可能性を尺度として使用するパフォーマンス ベンチマークを作成するにはどうすればよいでしょうか。

私が言いたいのは、システムがコードを 1 秒あたり 1000 回実行できる場合、テストでそれができるだけ 1000 に近くなることを確認したいということです。500しかできない場合、それは私が比較したいレートです.

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

ありがとうございました。

4

4 に答える 4

5

テストとは、合格/不合格のしきい値があることを意味します。パフォーマンステストの場合、これは遅すぎることを意味し、失敗し、十分に速く、合格します。失敗した場合は、やり直しを開始します。

失敗できない場合は、実際にテストするのではなく、ベンチマークを行っています。

「システムは実行可能」について話すときは、「機能可能」を定義する必要があります。多数のハードウェアパフォーマンスベンチマークのいずれかを使用できます。砥石、ドライストーンなどが人気です。または、データベースを多用するアプリケーションを使用している場合は、TPCベンチマークを確認することをお勧めします。または、ネットワークを集中的に使用するアプリケーションがあり、netperfを使用したい場合もあります。または、GUIを多用するアプリケーションで、ある種のグラフィックベンチマークを使用したい場合。

これらのいずれも、ある種の「能力」測定を提供します。1つ以上選択してください。それらはすべて良いです。同様に議論の余地があります。競合他社に等しく偏り、あなたから離れます。

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

十分なデータを収集すれば、いくつかのベンチマーク数とパフォーマンス数の間に何らかの相関関係を確立できます。ワークロード、ハードウェア構成、OSバージョン、仮想マシン、DBサーバーなどに基づいて、あらゆる種類のバリエーションが表示されます。

十分に異なる構成の十分なボックスからの十分なデータがあれば、最終的には、「このハードウェア、ソフトウェア、チューニングパラメーター、および構成が与えられた場合、私のソフトウェアは1秒あたり[X]トランザクションを実行することを期待します」というパフォーマンスモデルを開発できます。それは「有能」の確かな定義です。

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

于 2009-07-08T20:46:10.020 に答える
2

ユニットテストはパフォーマンステストを行うための適切な方法ではないと彼が言ったとき、私はブライアンに同意します。ただし、さまざまなシステム構成/環境で実行する統合テストとして使用できる短い例をまとめました。これは、この点に関して何ができるかを示すためのものであり、システムのパフォーマンスに関する公式の声明を裏付けるほど正確な結果を提供するものではないことに注意してください。

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);
    }
}
于 2009-07-08T20:51:31.960 に答える
0

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

私がすることは、テストが最近のビルドを引き継いだデルタ CPU 時間をプロットすることだけです。CPU時間はリアルタイムではないことに注意してください。実際の値はそれほど重要ではありません。重要なのは、どれだけ変化したかです。

テストの実行時間を大幅に変更したアルゴリズムに変更をコミットすると、その原因となった特定の変更セットに簡単にズームインできます。私が本当に気にかけているのは、これらの重要なポイントです。必ずしも絶対値ではありません。リアルタイム システムにはしばしば多くのトレードオフがあり、これらは単純な比較としてテスト フレームワークに常に表現できるとは限りません。

最初は絶対時間を見て正規化するのが妥当に思えますが、実際にはシステムとターゲット システム間の変換は非線形になります。たとえば、キャッシュ プレッシャ、スワップの使用状況、ターゲット システムのディスク速度などにより、システムとは異なるしきい値で爆発するようにテストします。

この点で正確なテストが絶対に必要な場合は、ターゲット システムを複製し、それをテスト スレーブとして使用しますが、想定される環境と同様の環境で使用します。

私の場合、実際にはファームウェアを DSP にダウンロードしたり、リモートで電源を入れ直したり、シリアル ポートから応答を読み取ったり、クラッシュしたために応答がなかったりする可能性があります。

--ジェフク++

于 2009-07-08T20:30:17.743 に答える