Javaパフォーマンス第2版

第2章 パフォーマンス・テストのアプローチ パフォーマンステストへのアプローチ

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

この章では、パフォーマンステストから結果を得るための4つの原則、すなわち、実際のアプリケーションを テストすること、スループット、バッチ処理、応答時間を理解すること、ばらつきを理解すること、そして、テス トを早期に頻繁に行うことについて議論する。これらの原則は、後の章で述べるアドバイスの基礎となる。パフォーマンスエンジニアリングの科学は、これらの原則によってカバーされている。アプリケーションに対してパフォーマンステストを実行するのは良いことだが、そのテストの背後に科学的な分析がなければ、間違った、あるいは不完全な分析につながることがあまりにも多い。この章では、テストが有効な分析を生み出すようにする方法について説明する。

後の章で示される例の多くは、株価システムをエミュレートする一般的なアプリケーションを使用している。

実際のアプリケーションをテストする

第一の原則は、テストは実際の製品で、その製品が使用される方法で行うべきであるということである。大雑把に言えば、パフォーマンステストにはマイクロベンチマーク、マクロベンチマーク、メソベンチマークの3つのカテゴリーがある。それぞれに利点と欠点がある。実際のアプリケーションを含むカテゴリーが最良の結果をもたらす。

マイクロベンチマーク

マイクロベンチマークとは、複数の代替実装のうちどれが望ましいかを判断するために、小さな単体パフォーマンスを測定するために設計されたテストである。スレッドプールを使用した場合とスレッド作成時のオーバーヘッド、ある算術アルゴリズムの実行時間と代替実装の実行時間などである。

マイクロベンチマークは良いアイデアのように思えるかもしれないが、開発者にとって魅力的なJavaの特徴、つまりジャストインタイム・コンパイルとガベージコレクションが、マイクロベンチマークを正しく書くことを難しくしている。

マイクロベンチマークはその結果を使わなければならない

マイクロベンチマークは、様々な点で通常のプログラムとは異なる。まず、Javaコードは最初の数回はインタプリタされるため、実行すればするほど速くなる。このため、（マイクロベンチマークに限らず）すべてのベンチマークには通常、JVMがコードを最適な状態にコンパイルするためのウォームアップ期間が含まれる。

その最適な状態には、多くの最適化が含まれる可能性がある。例えば、50番目のフィボナッチ数を計算するメソッドの実装を計算する、一見単純なループがここにある：

public void doTest() {
    // Main Loop
    double l;
    for (int i = 0; i < nWarmups; i++) {
        l = fibImpl1(50);
    }
    long then = System.currentTimeMillis();
    for (int i = 0; i < nLoops; i++) {
        l = fibImpl1(50);
    }
    long now = System.currentTimeMillis();
    System.out.println("Elapsed time: " + (now - then));
}

このコードは、fibImpl1() メソッドの実行時間を計測したいので、まずコンパイラをウォームアップし、それからコンパイルされたメソッドを計測する。 ...