このページは、以下の英語ページの抄訳です。最新の情報については、
英語ページを参照してください。
この記事のオリジナルは、Glenn Paulley が sybase.com に 2009 年 3 月に掲載したものです。その中で、Glenn はシンプルなベンチマークや測定バイアスへのフォーカスの危険性について語っています。
私は、ここ数週間、
SQL Anywhere が関わるもの、関わらないものにかかわらず、公開されている複数のパフォーマンス分析を見てきました。
概して、これらの「ベンチマーク」は、非常にシンプルでした。シンプルなベンチマークは、複雑なものと比較して開発の努力は少なくてすむため、これは想像の範囲でしたが。
私が頻繁に目にするパフォーマンス分析に、例えばシンプルに 1 つのテーブルに行をできるだけ高速に挿入できるかというようなものがあります。「Knowing that value is a Good Thing (TM)」（その価値を知ることは良いことです） - そして、私たちのラボでもこれの（その他も）価値を判断するために特定のテストをします。しかしながら、データベースアプリケーションのパフォーマンス分析には、以下の 2 点を指摘したいと思います。
- ほとんどの場合、このようなシンプルなテストはアプリケーションの動作をうまく表していないため、あまり意味がありません。また
- シンプルなオペレーションのきめの細かいテストは、幅広いパフォーマンス要素に依存する可能性があり、効率性のわずかな差であってもテスト結果を大幅にゆがめてしまう可能性があります。
2 つ目について、Raj Jain 氏のパフォーマンス分析の書籍 [1] 「Common Mistakes and How to Avoid Them」(よくある間違いとその間違いを避ける方法) の第 2 章から以下を引用したいと思います。
パフォーマンスに影響を及ぼす様々なシステムやワークロードパラメーターのランダム性を理解することはとても重要です。これらのパラメーターの中には、他よりは理解されているものもあります。例えば、アナリストは、コンピューターシステムにおけるページ参照の分散について知っているかもしれません。このような場合によくある間違いが、ディスクがボトルネックにある可能性があり、ページ参照よりもパフォーマンスへの影響があるかもしれないにもかかわらず、ページ参照分散を要素として使用してしまうことです。要素の選択は、関連性に基づいて行われべきで、アナリストの要素に関する知識にもとづいて行われるべきではありません。
実験的なセットアップにおける潜在的バイアスまたは明示的なバイアスのインパクトは、過小評価することができません。実際、最近の
論文[2] では、SPEC CPU2006 ベンチマークスイートのようなシンプルなコンパイラーベンチマークは、著者が「測定バイアス」と呼ぶ問題を避けるに十分なほど多様ではありません。この論文の概要は以下のとおりです。
この論文は、驚くべき結果を示しています。実験的なセットアップにおいて、表面的に無害な側面を変更することで、システムの調査員は実験から誤った結論を導きだしてしまう可能性があります。実験的なセットアップにおける無害な側面と思われるものは、実際には評価において大きなバイアスをもたらします。この現象は、自然科学や社会科学において測定バイアスと呼ばれています。我々の結果では、測定バイアスは、コンピューターシステムの評価において、「重要」かつ「よくあること」であることを表しています。「重要」という言葉で意味するところは、測定バイアスがパフォーマンス分析において効果を誇張するあるいは不正確な結論を導いてしまうということです。「よくあること」というのは、測定バイアスが、我々が試みた全てのアーキテクチャー（Pentium 4、Core 2、そして m5 03CPU）で試みたコンパイラーのどちらでも (gcc と Intel の C コンパイラー)、さらにはほとんどの SPEC CPU2006 C プログラムで起こることを意味しています。そのため、我々は測定バイアスを無視することはできません。にもかかわらず、ASPLOS、PACT、PLDI、CGO からの最近の 133 もの論文の文献調査において、測定バイアスについて適切に考慮された実験結果に基づく論文はありませんでした。
Mytkowicz 氏らの結果は、例えば、
(a)プログラムスタックのアライメントに影響するマシンの環境変数に必要なメモリの量や、
(b)キャッシュラインの「hot」ループのアライメントに影響する最終実行ファイルのコンパイルされたオブジェクトのリンクオーダーなど、
テストにおける環境的な要素で発生した測定バイアスが、このケースでは、O3 コンパイラー最適化の効果である
測定されるべきパフォーマンス要素に打ち勝ってしまうことを示しています。
彼らの結果では、実験的なセットアップを修正することが、
それ自体パフォーマンスを 0.8 から 1.1 にスピードアップさせてしまうことを示しています。これはつまり、これらの測定されていない要素によって、彼らのテストにおいてスピードが 20% 減速する可能性があり、また、10% アップする可能性があるということを示しています。
著者は、測定バイアスを避ける、あるいは検出するために、3つの提案をしています。これは私が見る限り、データベースアプリケーションのベンチマークでも同様に適用することが可能です。
それらは以下のものです。
- より大きなベンチマークスイートを活用する。測定バイアスを要素から除外するに十分になるよう多様化させる。
- 多数の実験的なセットアップを生成する。測定バイアスを発生させることで知られるパラメーターを変化させる。そして統計的メソッドを使用して結果を分析する。
- 測定バイアスに直面している場合でも、描かれた結論が有効であると確信を得るための略式の分析（インターベンション、測定、確認）を使用する。
[2] に注意を向けてくれた同僚の Nathan Auch に感謝します。
[1] Raj Jain (1991). The Art of Computer Systems Performance Evaluation, John Wiley and Sons, New York. ISBN 0-471-50336-3.
[2] Todd Mytkowicz, Amer Diwan, Matthias Hauswirth, and Peter F. Sweeney (March 2009). Producing Wrong Data Without Doing Anything Obviously Wrong! In Proceedings, 14th International Conference on Architectural Support for Programming Languages and Operating Systems, Washington, DC, pp. 265-276.
===
SAP SQL Anywhere に関する詳細情報は、<英語> を参照してください。
上記のコミュニティーに掲載されている技術情報は、順次
SQL Anywhere 日本語コミュニティ
に掲載しています。
SQL Anywhere に関してはまずは
こちらをご参照ください。無期限でご利用いただける無償の Developers Edition もこちらからダウンロードが可能です。
SQL Anywhere に関して技術的な質問のある方はコミュニティに登録し、
「Ask a Question」機能をご利用ください。
Language には「Japanese」、
Primary Tag には「SAP SQL Anywhere」を選択
User Tagに「sql anywhere」「sql anywhere Japanese question」
を入力してください。
不具合につきましては、サポート契約者様専用の問い合わせ方法にてお問い合わせください。
======================
ご購入に関するお問い合わせ
こちらよりお問い合わせください。
