第2章 パフォーマンステストのアプローチ
実アプリケーションでテストする
パフォーマンステストに利用できるコードは、マイクロベンチマーク、マクロベンチマーク、メゾベンチマークの３種類にカテゴライズできる。
マイクロベンチマーク
これは、とても小さな単位でパフォーマンスを測定するためのテストです。マイクロベンチマーク用の正しいコードを書くことはとても難しいです。
- 処理結果を利用しなければならない 処理結果を変数に書き込むだけでは、コンパイラが処理が不要と判断して処理自体を削除する可能性があるので、変数に書き込んだあとは読み出す必要があります。
- 不必要な処理を含めてはならない テスト用に乱数を生成する処理など、ベンチマーク用の処理を計測時間に含んでしまうと、意図したベンチマークが取れないので気をつける必要があります。
- 正しい入力に基づいて測定しなければならない テストように生成する乱数が入力値の範囲内にない場合など、使われ方を反映したとは言えません。適切な範囲の値を使うようにする必要があります。
なお、ベンチマークを取る際は、ウォームアップを行って置かないとコード本体だけでなくコンパイルのパフォーマンスも測定してしまうので、気をつける必要があります。 マイクロベンチマークの作成は容易ではなく、役に立つケースは限られます。落とし穴について理解して、適切なマイクロベンチマークの作成メリットがあるのか（あるいは、よりマクロなレベルのテストに注力する方がよいのか）どうかを理解しましょう。
スループット、バッチ、レスポンスタイムを理解する
バッチ（一括）処理の測定
パフォーマンス測定するための最も簡単な方法は、ある作業にどの程度の時間がかかっているかを調べるというものです。 Javaは、JIT(just-in-time)コンパイルという厄介者がいて、コードが完全に最適化され十分なパフォーマンスを発揮するためには数分またはそれ以上の時間が必要です。このため、Javaのパフォーマンスに関する調査ではウォームアップの時間がとても重視されています。
スループットの計測
スループットとは、ある一定の時間内にどの程度の寮の処理を行えるかということを表します。クライアント-サーバー型のテストでスループットを計測する際には、クライアント側にシンクタイム（think time。何も処理を行わずに待つ時間）があってはなりません。 通常は、一定時間でのリクエストの総数ではなく１秒間あたりのリクエストの数がスループットとして扱われます。この値は、TPS(transactions per second)、RPS(requests per second)、OPS(operations per second)と呼ばれます。 スループットを計測するテストでは、レスポンスタイムを測る場合よりも少数のクライアントを使うようにして負荷を下げるのが一般的です。 固定的な一連の処理を測定するというわけではないため、スループットの測定ではほぼ必ず十分なウォームアップの時間が用意されます。
レスポンスタイムのテスト
レスポンスタイムとは、クライアントがリクエストを送信してからレスポンスを受け取るまでの経過時間を表します。レスポンスタイムのテストでは、ユーザの振る舞いをより正確に模倣することが目指されているため、クライアントのスレッドが処理の間に一定時間スリープするシンクタイムを設けます。 レスポンスタイムの算出方法は、2つあります。1つは平均です。もう1つは、レスポンスタイムをリクエストのパーセンタイル値として表現する方法です。例えば、90パーセンタイルあたいは1.5秒といったように表現されます。この場合、90%のリクエストでレスポンスタイムは1.5秒以下で、残りの10%では1.5秒以上という意味になります。 この2つの値の違いは、外れ値の扱いに現れます。平均値の計算にはすべての値が含まれるため、他と大きく異なる値があると平均値に影響します。
