アクティブベンチマーキング

アクティブベンチマーキング

デバッグベンチマークは長年行ってきた経験があり、驚くほど多様で滑稽な失敗モードを見てきました。問題は、ベンチマークツールが、それが何をテストしているのかを理解せずに実行されたり、結果が有効であることを確認せずに実行されたりすることが多いことです。これにより、後々まで悩まされることになる、不適切な開発やアーキテクチャの選択につながる可能性があります。以前、この状況を次のように要約しました。

カジュアルなベンチマーキング：Aをベンチマークするが、実際にはBを測定し、Cを測定したと結論付ける。

正確なベンチマーキングは重要です。企業は、ベンチマークの結果に基づいて、異なるサーバープラットフォーム、プログラミングスタック、データベース、またはアプリケーションベンダーを選択するかもしれません。正確な結果は、価格性能で最高のものを選択し、負荷下でスケールする可能性が最も高いオプションを選択するなど、良い選択を可能にします。

このページでは、私が「アクティブ」および「パッシブ」ベンチマーキングと呼ぶものを紹介します。アクティブベンチマーキングは、ベンチマークの真のターゲットを正確にテストし、その結果を正しく理解するのに役立ちます。開始時にはより多くの労力が必要ですが、後々、より多くの時間とお金を節約できます。

これを実際に見るには、例にジャンプしてください。

このページについて： 要約、パッシブベンチマーキング、アクティブベンチマーキング、チェックリスト、例、統計分析、更新情報。例：Bonnie++。

要約

アクティブベンチマーキングを実行するには：

1. 可能であれば、ベンチマークが長時間、定常状態で実行されるように設定します（例：数時間）。
2. ベンチマークの実行中に、他のツールを使用して、関与するすべてのコンポーネントのパフォーマンスを分析し、ベンチマークの真の制限要因を特定します。

アクティブベンチマーキングのプロセスは、任意のアプリケーションのパフォーマンス分析に似ています。違いの1つは、分析を容易にする可能性があることで、分析を開始するための既知のワークロード（適用されたベンチマーク）があることです。

パッシブベンチマーキング

ベンチマークは一般的に実行され、完了するまで無視されます。それがパッシブベンチマーキングであり、主な目的はベンチマークデータの収集です。データは情報ではありません。

提示される技術的な結果がベンチマークの結果のみである場合、それは明白な兆候です。私は無数のスライドデッキ、ブログ記事、記事を見てきましたが、それらは比較結果の印象的な棒グラフを示していますが、それを裏付ける技術的な証拠はありません。それらの多くを徹底的に調査するのが私の仕事でしたが、通常、それらはほぼ毎回間違っているか、誤解を招くものであることがわかりました。主な理由は、それらが追加の分析なしに「実行して忘れる」スタイルでパッシブに実行され、すべての問題が見過ごされたためです。

アクティブベンチマーキング

アクティブベンチマーキングでは、ベンチマークがまだ実行中（完了後だけでなく）である間に、他のツールを使用してパフォーマンスを分析します。ベンチマークが意図した対象をテストしていること、そしてそれが何を意味するのかを理解していることを確認できます。これにより、テスト中のシステムまたはベンチマーク自体の真の制限要因を特定することもできます。

アクティブベンチマーキングを実行するには、OSが提供する任意のパフォーマンス分析ツールを使用できます：vmstat、iostat、mpstat、sar、top、tcpdump/snoop、perf、bcc+eBPF/DTrace/SystemTap、strace/trussなど。また、これらのツールの使用をガイドするために、パフォーマンス分析方法論に従うこともできます。USEメソッドは、ハードウェアおよびソフトウェアリソースといった一般的な制限要因を特定するため、特に適しています。

他の人がアクティブベンチマーキングを行ったかどうかを見分ける方法：

• ベンチマークの実行中に他のツールを実行しましたか？スクリーンショットを提供できますか？
• ベンチマーク結果がXであり、2X（2倍速い）ではない理由を説明できますか？つまり、制限要因は何ですか？

理想的には、制限要因（または疑われる制限要因）をベンチマーク結果とともに含めます。たとえば、「ファイルシステムの結果はサーバーのCPU速度によって制限され、ベンチマークはシングルスレッドでした」などです。証拠として、このステートメントには、ベンチマークがシングルスレッドでCPUバウンドであったことを示すスクリーンショットを含めることができます。たとえば、Linuxでは「pidstat -t 1」を、Solarisでは「prstat -mLc 1」を使用します。

ベンチマークの実行中の分析に加えて、事前にその設定も分析する必要があります。理想的には、ベンチマークはオープンソースであり、Makefileやコンパイラオプションだけでなく、ソースコードも調査できます。

例

以下は、分析に使用されたツールを示す、アクティブベンチマーキングの実践的な例です。

• Bonnie++：SmartOS/illumosとFedora/Linuxの両方での詳細な分析。

問題チェックリスト

アクティブベンチマーキングを使用して特定できる一般的な落とし穴は、ベンチマークが次のいずれかである場合です。

• 他のシステムイベント（近隣プロセスを含む）によって乱される。
• ソフトウェアによって課されたリソース制御によってスロットルされる。
• ベンチマーククライアントとサーバー間のネットワークによってスロットルされる。
• ベンチマークソフトウェアがシングルスレッドであることによって制限される。
• 比較ベンチマークを実行する際に、異なるクライアントまたはサーバーソフトウェアバージョンをテストしている。
• ファイルシステムI/Oではなく、ディスクI/Oをテストしている。
• 非現実的なワークロードを適用している。

最も一般的なケースは、ベンチマークが主張していることを実際にはテストしていないというもので、これはアクティブベンチマーキングを使用して特定できます。場合によっては、結果は正しく解釈できるようになったため、依然として有用です。

統計分析

これは、ベンチマークが完了した後の数値ベンチマーク結果の統計分析です。これは、結果をより良く理解し、信頼性を高めるために、生のベンチマークデータから新しい情報を開発するための有用な演習と見なされることがよくあります。しかし、ベンチマーク結果が最初から間違っていたり、誤解を招くものであった場合、統計分析は事態を悪化させる可能性があります。健全な統計的手法は、実際には偽であるにもかかわらず、ベンチマーク結果を信頼できるように見せかけることができます。開発された新しい情報も偽である可能性があり、問題がさらに複雑化します。

誤った結果が得られた場合の唯一の良い結果は、統計分析がそれらを信頼できない（例：変動係数が高すぎる）と判断し、分析が実際のベンチマークで何がうまくいかなかったかを理解することに移ることです。実際には、これは私が望むほど頻繁には起こりません。多くの場合、誤ったターゲットがベンチマークされていますが、結果は統計的に健全です。

統計分析は、アクティブベンチマーキングの後に役立ちます。つまり、有効な数値がある場合です。まずiostat、次にRです。

更新情報

• Surge 2013でBenchmarking Gone Wrongというライトニングトークを行い、アクティブベンチマーキングの記憶に残る逸話を提供しました。