Javaパフォーマンスを読んでる。
自分なりに理解した内容をメモる。
2章: パフォーマンステストのアプローチ
パフォーマンスのベンチマーク計測方法
実アプリケーションでテストするのが最も信頼できる数値を得られる。 ただし、実施が簡単ではなかったりする。
対して、timestampなどを計測するコードを挟み込んでコードの特定部分のみの実行速度を測ったりする「マイクロベンチマーク」という手法もある。 こちらは簡単に実行できるが、測定値の信頼度は低かったりする。（測定したいコードそのものがコンパイル時の最適化によってごっそりなくなってたりする） その中間くらいの計測方法としてメゾベンチマークというのもある。 どこで計測を実行するかは目的やメリデメのバランス問題になるが、メゾベンチマークあたりで計測するのが有用なケースは多いっぽい。 それでも実アプリケーションではないので参考にならない可能性があることをわかったうえでそこでテストするって感じ。
スループット、バッチ、レスポンスタイム
■ バッチ処理でのパフォーマンス測定について
Javaの場合にはウォームアップ（コンパイルが十分に行われてパフォーマンスが最高に達するまでの時間）を考慮する必要がある。 バッチ処理の場合においては、ウォームアップ後にて測定を行うのが良さげ
■スループットの計測
ある一定の時間内にどの程度の量の処理を行えるかということを表す。 クライアントはリクエストとリクエストの間に時間（シンクタイム）をおいてはならない。 クライアント側のスペックが問題になりやすいので気をつける。
■ レスポンスタイムの計測
クライアントがリクエストを送信してからレスポンスを受け取るまでの経過時間を測定する。 クライアントは実際のユーザーの動作を模して、レスポンスと次のリクエストの間に一定のシンクタイムを設ける。 たぶん、高負荷時の結果を測定したいわけではないということだと思う。
■ パーセンタイル値
計測結果のまとめ方に、平均値を取るやり方と、パーセンタイル値を取るやり方がある。 javaの場合にはGCにより外れ値がでやすいため、パーセンタイル値の方が合っていそう。
不安定性を理解する
計測できる値はテストのたびに異なる。これが優位な値なのかランダム性によるあたいなのか判断しないといけない。 統計的な手法によって判断する方法がある。（t検定など）
パフォーマンステストをいつやるか？
早期から自動テストに組み込んで置くと良い。 開発サイクルとのバランスを考慮する。
