ベンチマーキングを実施する理由：
- チューニング
- 開発
- 開発中の非回帰テスト (定期的に実行される自動化されたパフォーマンスのテストスイート)
- キャパシティプランニング
- トラブルシューティング
- ネットワークのスループットを調査するなど、コンポーネントが最高の性能で動作するかを調べる
- マーケティング (benchmarketing)
- OSS
- システム設計
- 特に市販製品の価格/パフォーマンス比
ファイルシステムとストレージに関する9年間のベンチマーキングを調べた研究 [Traeger08] では、論文で用いられているベンチマークの大半には欠陥があると述べている。
優れたベンチマークのエッセンス：
- 反復可能
- 比較のため
- 観察可能
- 分析・理解のため
- ポータブル
- 異なる環境でも横断的に行うため
- 容易なプレゼンテーション
- 結果の理解のため
- 現実的
- 顧客のため (計測値が現実を表しているか)
- 実行可能
- テストの素早い変更のため
ベンチマークを使うために理解している必要があること：
- 何がテストされているか
- 制限要因 (複数かもしれない) はなにか
- 副次的な影響はないか
- 結果から何がわかるか
ベンチマークソフトウェアの挙動、システムの応答、結果と環境の関係を深く理解する必要がある。 ベンチマーク実行中にシステムのパフォーマンス分析を行うことが重要。
初心者は数値を見て勘所が働かないので注意。
例：
- A をベンチマークしたつもりだが、実際には B を計測しており、C を計測したと結論づけている。
- ディスクのパフォーマンスを計測したつもりが、実際にはファイルシステムのそれを計測していた
- 人気のあるツール＝正しいツールか?
- ソフトウェアにバグがあるかもしれないし、結果の解釈が間違っていることもある
詳細を省いて結果のみで語るのは危険である。
ベンチマークの結果の分析に1週間未満しかかけていない場合には、そのベンチマークはおそらく間違っている
繰り返しになるが、パフォーマンス分析はベンチマーク実行時に行わなければならない。 慎重な分析をする時間がない場合には、チェックする時間がなかった前提条件をリストアップして結果に添付するとよい。後の詳細な分析のための To-Do リストにもなる。例えば：
- ベンチマークツールにはバグがないことが前提
- ディスク I/O テストが実際にディスク I/O を計測していることが前提
- ツール自体の複雑さのために分析を邪魔されないように、オープンソースで内部構造を検討できるものがよい
- マイクロベンチマークでは C で書かれたものを選ぶのがおすすめ (?)
- ベンチマークのベンチマーキング問題
- 実際のワークロードを模倣するワークロードか
- 例：実際のワークロードはすべてファイルシステムキャッシュから実行されておりディスク I/O とは無関係と予想されている一方で、ディスクベンチマークツールを使ってディスクパフォーマンスをテストしていた
- 特定のワークロードに対してソフトウェアを最適化していないか
- ワークロードは変化してないか
ツールによるなんらかの結果は、成功を示すとは限らない。例えば：
- Web サーバパフォーマンステストツールが報告した高すぎるレイテンシ値は、すべてのリクエストがファイアウォールでブロックされたことによるタイムアウトに起因していた
特にマイクロベンチマークツールは、実世界を特徴づける一連の計測値の平均にもとづいた安定かつ一定のワークロードを与えることが多い。平均はばらつきを無視してしまうので、本番システムで発生しているワークロードをシミュレートできているとは限らない。
結果に対する外部からの副次的影響を考慮しなければならない。副次的影響を取り除くために一般的に用いられる手法は、ベンチマークを長時間実行することである。原則として1秒未満であってはならない。 短期間のテストは以下のような影響を受けやすい。
- デバイス割り込み
- カーネルによる CPU スケジューリングの変更
- CPU キャッシュのウォーム度
副次的影響が考えられる場合、分析のためにデータを集めて外れ値をあぶり出す必要がある。
ベンチマークテストの2つの結果を比較する場合、意図した変更以外の要因 (例えばネットワークなど) が変更されていないか。 クラウドにおけるベンチマークは、外れ値を避けるために複数のインスタンスをテストして分布と平均をとることを推奨する。
省略。
省略。
ベンダーが主張するベンチマークは、技術的には正しいが、実際に計測する情報が意図せず不完全なものになっていたり意図的に必要な情報を省略したことによって、しばしば顧客の誤解を招く。ベンチマークを鵜呑みにせず、ベンチマーク対象のシステムを注意してチェックする必要がある。
ベンチマークで高得点を取ることだけを目的とした製品のこと。ベンチマーク最適化とも。
詐欺。
- (↑ 人工的)
- マイクロベンチマーキング
- シミュレーション
- リプレイ
- 本番
- (↓ 現実的)
人工的なワークロードを使って特定のタイプのオペレーションだけをテストするもの。具体的にはある1つの種類のファイルシステム I/O・データベースクエリー・CPU 命令・システムコールなど。
- 利点
- 単純・反復可能・ポータブル
- 問題点
- あくまで人工的なワークロードに注目している
表：これまでの章で触れたマイクロベンチマークツール
| リソース | マイクロベンチマークツール |
|---|---|
| CPU | UnixBench・SysBench |
| メモリ I/O | Imbench |
| ファイルシステム | Bonnie・Bonnie++・SysBench・fio |
| ディスク | hdparm |
| ネットワーク | iperf |
シーケンシャル/ランダム I/O・I/O サイズ・方向 (read/write) をテストするファイルシステム用のマイクロベンチマーツールを考える。
表：ファイルシステム用マイクロベンチマークツールの例
| 番号 | テスト | 意図 |
|---|---|---|
| 1 | シーケンシャルな 512 B の読み出し | 最大の (現実的な) IOPS をテスト |
| 2 | シーケンシャルな 128 kB の読み出し | 読み出しスループットの上限をテスト |
| 3 | シーケンシャルな 128 kB の書き込み | 書き込みスループットの上限をテスト |
| 4 | ランダムな 512 B の読み出し | ランダム I/O の効果をテスト |
| 5 | ランダムな 512 B の書き込み | 書き直しの効果をテスト |
他に加えられる要素：
-
ワーキングセットサイズ：アクセスされるデータのサイズ (例：合計ファイルサイズ)
- メインメモリよりはるかに小さい：ファイルシステムソフトウェア (キャッシュ) のパフォーマンス
- メインメモリよりはるかに大きい：ファイルシステムキャッシュの効果を最低限にしてディスク I/O のテストに近づける
-
スレッド数
- ワーキングセットが小さいことが前提条件
- シングルスレッド：現在の CPU クロックスピードにもとづいたファイルシステムパフォーマンス
- マルチスレッド：システム (ファイルシステムと CPU) のパフォーマンス上限
条件を追加すると、テストケースの組み合わせが倍増していく。テストセットを縮小するための統計的分析のテクニックがある (←何?) 。
トップスピードに注目するベンチマークツールによるテストは「晴れの日」のパフォーマンステストと呼ばれる。一方で競合・副次的影響・ワークロードのばらつきなどの望ましくない条件のテストは「曇りの日」のパフォーマンステストと呼ばれる。
顧客がアプリケーションに与えるワークロードをシミュレートするベンチマークツール (マクロベンチマークとも呼ばれる) も存在する。本番環境のワークロードの特性を掴んだ結果 (2章：メソドロジ) にもとづいてシミュレートする特性を決める。
ワークロードシミュレーションは、個々の要求が前の要求と無関係なステートレスなものと、少なくとも1つ前の要求に依存するステートフルなものに分けられる。ステートフルなシミュレーションは例えば、要求を状態として表現し、状態遷移の確率を計算するマルコフモデルで実現できる。
- 利点
- 実際のワークロードで得られるパフォーマンスに似た役立つ結果を生み出せる
- マイクロベンチマーキングで調査するのでは時間がかかる多数の要素を組み込める
- マイクロベンチマーキングでは全く捉えられないシステム内の複雑な相互作用の効果も調べられる
- 問題点
- ばらつきを無視することがある
- ソフトウェアの利用パターンの変化とともにシミュレーションの更新が必要
- 結果の比較が難しくなる
本番環境でのトレースログを利用して再現することで、実際に行われたオペレーションと比較する手法。一見すると本番環境でのテストと同じぐらい効果的に思えるが、環境の多少の違い (サーバ上の特徴やレイテンシ) などによって、シミュレートされたワークロードと大差のないものになってしまうことがある。
ベンチマークを公平で意味のあるものにするために、独立機関が開発した産業標準のベンチマークがある。TPS (Transaction Per Second) と同様の指標には以下がある。
- MIPS (Millions Instructions Per Second)
- 実際に行われる処理は命令タイプによってまちまちなので、プロセッサが異なるアーキテクチャ間での比較は難しい
- FLOPS (FLoating-point Operations Per Second)
- MIPS とよく似ているが、浮動小数点演算を多用するワークロードのための指標
TPC (Transaction Processing Performance Council) は、データベースのパフォーマンスに重点を置いて、さまざまな産業標準を作成・管理している。TPC-C, TCP-DS, ... など。
SPEC (Standard Performance Evaluation Corporation) は、産業標準ベンチマークの標準セットを開発・公開している。SPEC CPU2006, SPECjEnterprise2010, ... など。
| メソドロジ | タイプ |
|---|---|
| 12.3.1 パッシブベンチマーキング | 実験による分析 |
| 12.3.2 アクティブベンチマーキング | 観察による分析 |
| 12.3.3 CPU プロファイリング | 観察による分析 |
| 12.3.4 USE メソッド | 観察による分析 |
| 12.3.5 ワークロードの特性の把握 | 観察による分析 |
| 12.3.6 カスタムベンチマーク | ソフトウェア開発 |
| 12.3.7 ランプロード | 実験による分析 |
| 12.3.8 サニティチェック | 観察による分析 |
| 12.3.9 統計的分析 | 統計的分析 |
いわゆる「ベンチマーク」で、ベンチマークデータの収集のためものである。 ベンチマークツールを選択し、オプションを指定して実行、実行結果を得るというような流れである。
簡単だが誤りを起こしやすい。
ベンチマークを実行中にほかのツールを使ってパフォーマンスを分析する。 ベンチマークテストがテストしていると主張しているものが本当にテストされているか、それが何なのか自分が理解していることを確認できる。
例：
- 仮想環境化における Fedora と SmartOS について、Bonnie++ でファイルシステム I/O ベンチマークをとると (パッシブ) SmartOS のほうが 3.1 倍速かった。
iostatとvfsstatでディスク I/O をチェックすると Bonnie++ の結果よりも IOPS が低かった。straceとtrussでファイルシステムへの書き込みをチェックすると、Fedora では 4 kB の書き込みだったのに対し、SmartOS は 128 kB の書き込みをしていた。- 分析の結果、システムライブラリの
putcのバッファリングサイズによる違いだった。setbuffer()で Fedora 上の Bonnie++ が 128 kB のバッファを使うように調整するとパフォーマンスは改善した。
アクティブベンチマーキングの一部として行われることが多い。ディスクベンチマークなど CPU に関係なさそうな場合もやってみる価値はある。
ベンチマークの過程で USE メソッドを使うと、テストの限界を確実に見つけられる。ハードウェアかソフトウェアの何らかのコンポーネントの使用率が 100% に達しているか、システムが限界に達していないかである。
2章で紹介。
単純なベンチマークは自作するといいかもしれない。複雑さは分析の邪魔となるため、できるかぎり単純で短いものにする。C 言語プログラムは書いたことと実際の実行内容が近くなるので通常は C を使うとよい。ただしコンパイラの最適化の影響は考慮する必要がある。
仮想マシン・非同期 GC・JIT などを使う言語では、信頼できる精度を出せるようにデバッグ・コントロールするのがはるかに難しいので推奨しない。
カスタムベンチマークを書くと、ターゲットの細部が明らかになり、それが後で役立つ可能性がある。例えばデータベースベンチマークを開発すると、本番環境では使われない、パフォーマンス向上のためのさまざまなオプションを API がサポートしていることが分かる場合がある。本番環境は、それらのオプションが作られる前に開発されたのである。
カスタムベンチマークは、単純な負荷を生成に集中すればよい (ロードジェネレータ)。そして計測は他のツールに任せる。ランプロード (ramp load) はそのための方法の一つである。
これは、システムが処理できるスループットの上限を判断するための単純なメソッドである。小さい差分で負荷を加えていき、限界に達するまで得られたスループットを計測する。結果をグラフにすることでスケーラビリティのプロファイルを示すことができ、視覚的またはスケーラビリティモデル (2章) による検証が行える。
このアプローチでは、スループットとともにレイテンシも計測する。特にレイテンシの分布が重要である。システムが限界に近づくと、キューイングの遅れが顕著となり、レイテンシが高くなる。負荷を上げすぎると、レイテンシが高くなりすぎ、結果はまともなものとは考えられなくなる。
これは、ベンチマークの結果になにかおかしな部分が含まれていないかどうかをチェックすることである。例えば何らかのコンポーネントがネットワーク帯域幅・コントローラの帯域幅・インターコネクトの帯域幅・ディスクの IOPS など既知の限界を超えなければ得られないような結果になっていないかが含まれる。
チェックすべきベンチマークの結果を渡されたら、そのような限界を見つけるために、与えられた数値を使ってどのような単純合計ができるかを考える。システムにアクセスできる場合は、新しい観察や実験によってテスト結果をさらにテストできるだろう。
統計的分析はコレクションに対する処理で、ベンチマークデータを検討する。次の 3 段階をたどる。
- 選択：ベンチマークツール・その構成・キャプチャするシステムパフォーマンス指標を選択
- 実行：ベンチマークを実行し、結果と指標の大規模なデータセットを収集
- 解釈：統計的分析によってデータを解釈しレポートを作成
ベンチマーク実行中のシステムの分析に重点を置くアクティブベンチマーキングとは異なり、統計的分析はベンチマークの結果を分析することに専念する。しかし全く分析を行わないパッシブベンチマーキングとも異なる。
このアプローチは、大規模システムへのアクセスが時間的に限られ、高くつく状況で行われる。指標のコレクションは高価なため、指標の信頼性の高さを保証する。指標の生成を技術以外の観点でチェックするには、問題を早い段階で見つけるためにより多くの統計的特性 (ばらつき・完全な分布・許容誤差など、2.8 統計参照) を集めるとよい。
また、実行中のシステムからできる限り多くのパフォーマンスデータを集め (データ収集のオーバーヘッドんいよって結果が損なわれないようにしながら)、あとでこのデータでフォレンジック分析が可能なようにする。データ収集には sar(1)・サードパーティ製品・カスタムツールなどで使える全ての統計情報をダンプすることが含まれる。
Linux では実行の前後に /proc の統計ファイルの内容をコピーするカスタムシェルスクリプトを用意するとよい。必要になったときのために可能なものは何でもコピーしておく。
結果や指標の統計的分析には、スケーラビリティ分析や待ち行列理論によるキューとネットワークとしてのシステムのモデリングも含めてもよい (2章)。
ベンダーからベンチマークの結果を入手したとき、理解を深め自分の環境に応用するためにいくつかの問いに答えてみるとよい。目的は、実際に計測されているものはなにか、その結果がどれぐらい現実的で反復可能なものかを明らかにすることである。最も難しい問いは「私は自分でこの結果を再現することができるだろうか」である。
- 一般的な問い
- テストされたシステムはどのような構成だったか
- 1 台のシステムでテストしたのか、システムのクラスタから結果を得ているのか
- ...