有意義なベンチマークを作成するために、どのようなアドバイスをいただけますか?
-
11-07-2019 - |
質問
私は、組織内のいくつかのチームが使用するフレームワークを開発しました。このフレームワーク上で開発されたこれらの「モジュール」は、まったく異なる動作をすることができますが、一部は他よりもかなりリソースを消費します。それらはすべて、入力でデータを受信し、分析および/または変換して、さらに送信します。
新しいハードウェアを購入する予定でした。上司から、モジュールに基づいてベンチマークを定義して実装し、さまざまなオファーを比較するように依頼されました。
私の考えは、適切に選択されたデータの束を入力として各モジュールを順番に開始することです。
何かアドバイスはありますか?この簡単な手順に関するコメントはありますか?
解決
あなたの質問はかなり広いので、残念ながら私の答えもあまり具体的ではありません。
最初に、ベンチマークは困難です。意味のある、再現可能な、信頼性の高い結果を生み出すために必要な努力を過小評価しないでください。
次に、パフォーマンスの目標は何ですか?スループット(トランザクションまたは1秒あたりの操作数)ですか?レイテンシー(トランザクションの実行にかかる時間)ですか?平均的なパフォーマンスを気にしますか?最悪の場合のパフォーマンスを気にしますか?絶対的な最悪のケースに関心がありますか、それとも90%、95%、またはその他のパーセンタイルが適切なパフォーマンスを得ることに関心があるのですか?
どの目標を持っているかに応じて、その目標に対して測定するベンチマークを設計する必要があります。そのため、スループットに関心がある場合は、メッセージ/トランザクション/入力を所定のレートでシステムに送信し、システムが維持されているかどうかを確認したいでしょう。
待ち時間に興味がある場合は、メッセージ/トランザクション/入力を送信し、それぞれの処理にかかる時間を測定します。
最悪のパフォーマンスに関心がある場合は、「現実的」と思われるものまで、システムに負荷を追加します。 (または、システム設計がサポートする必要があると言っているもの。)
第二に、これらのモジュールがCPUバウンド、I / Oバウンド、複数のCPU /コアなどを利用できるかどうかは言いません。異なるハードウェアソリューションを評価しようとすると、アプリケーションは、膨大な数のCPUよりも優れたI / Oサブシステムの恩恵を受けます。
第三に、最高の(そして最も難しい)ベンチマークは、システムに現実的な負荷をかけることです。つまり、実稼働環境からデータを記録し、このデータに新しいハードウェアソリューションを適用します。これを行うのは思ったより難しいです。多くの場合、これはシステムにあらゆる種類の測定ポイントを追加して動作を確認することを意味します(まだ持っていない場合)、既存のシステムを変更して記録/再生機能を追加し、再生をさまざまなレートで実行し、テスト用に現実的な(つまり、本番に似た)環境を取得します。
他のヒント
最も意味のあるベンチマークは、日常の使用でコードがどのように実行されるかを測定することです。それは明らかに最も現実的な数字を提供します。
いくつかの実際のデータセットを選択し、組織が毎日使用する同じプロセスを実行します。追加のクレジットについては、フレームワークを使用している人々と話し、「ベストケース」、「通常」、「最悪のケース」を提供するよう依頼してください。データ。プライバシーの問題がある場合はデータを匿名化しますが、パフォーマンスに影響を与える可能性のあるものは変更しないでください。
フレームワークではなく、2セットのハードウェアのベンチマークと比較を行っていることを思い出してください。すべてのソフトウェアをブラックボックスとして扱い、ハードウェアのパフォーマンスを単純に測定します。
最後に、データセットを保存し、それを使用してソフトウェアに加えた後の変更を同様に評価することを検討してください。
システムが複数のクライアントがすべて同時に呼び出しを処理できるようになっている場合、ベンチマークはこれを反映する必要があります。一部の呼び出しは一緒に再生されないことに注意してください。たとえば、25のスレッドが同時に同じ情報のビットをポストすると、サーバーエンドでロックが発生し、結果が歪む可能性があります。
ナットとボルトの観点から、Perlとそのベンチマークモジュールを使用しました気になる情報を収集します。
異なるハードウェアを比較する場合、トランザクションごとのコストを測定すると、パフォーマンスとハードウェアのトレードオフを適切に比較できます。 1つの構成で最高のパフォーマンスが得られる場合がありますが、コストがかかりすぎます。安価な構成では、十分なパフォーマンスが得られます。
「最悪のケース」をエミュレートすることが重要です。または「ピーク時間」負荷の。 「標準」でテストすることも重要です。ボリューム。これは、サーバーを適切に使用するためのバランスをとる行為であり、コストがかからず、必要なパフォーマンスが得られます。
ハードウェア構成全体のテストは、すぐに費用がかかります。別の実行可能なオプションは、最初に構成を測定し、次にモデルを使用して仮想システム全体でその動作をシミュレートすることです。
可能であれば、実際のシステムのクローンを使用して、ユーザー(またはプロセス)がフレームワークで行っている操作を記録してください。これにより、最も現実的なデータが得られます。考慮すべき事項:
- どの関数が最もよく使用されますか
- 転送されるデータ量
- 何も仮定しないでください。 「それが高速/低速になる」と思われる場合は、それに賭けないでください。 10件中9件のケースで、あなたは間違っています。
1 + 2のトップ10を作成し、そこから作業します。
つまり、古いハードウェアを新しいハードウェアに交換すると、最初のセットを購入してから1年ごとに実行が約10%速くなることが期待できます(その他の点でシステムがかなり同等の場合)。
特殊なシステムを使用している場合、数値は完全に異なる場合がありますが、通常、新しいハードウェアはそれほど変化しません。たとえば、有用なインデックスをデータベースに追加すると、クエリの実行時間が2時間から2秒に短縮されます。ハードウェアがそれを提供することはありません。
おわかりのように、ベンチマークソフトウェアには2種類のベンチマークがあります。まず、マイクロベンチマーク。コードの一部を単独で評価しようとしたとき、またはシステムが狭く定義されたワークロードをどのように処理するか。 Javaで作成された2つのソートアルゴリズムを比較します。 2つのWebブラウザーを比較して、それぞれがDOM操作操作を実行できる速度を比較します。次に、現実的なワークロードの下でソフトウェアシステムを評価しようとすると、システムベンチマークがあります(名前を付けたばかりです)。 Google Compute EngineとAmazon AWSで実行されているPythonベースのバックエンドを比較します。
Javaなどを扱うときは、VMが実際のパフォーマンスを実現する前にウォームアップする必要があることに注意してください。 time
コマンドで時間を測定すると、JVMの起動時間が含まれます。ほとんどの場合、起動時間を無視するか、個別に追跡する必要があります。
マイクロベンチマーク
最初の実行中、CPUキャッシュは必要なデータでいっぱいになります。ディスクキャッシュについても同じことが言えます。後続のいくつかの実行中、VMは引き続きウォームアップします。つまり、JITはコンパイルに役立つと判断したものをコンパイルします。これらの実行を無視して、後で測定を開始します。
多くの測定を行い、統計を計算します。平均、中央値、標準偏差、チャートをプロットします。それを見て、どれだけ変化するかを見てください。結果に影響を与える可能性のあるものには、VMでのGC一時停止、CPUでの周波数スケーリング、他のプロセスがバックグラウンドタスク(ウイルススキャンなど)を開始する場合、OSがプロセスを別のCPUコアに移動する場合があります( NUMA アーキテクチャを使用すると、結果はさらに顕著になります。
マイクロベンチマークの場合、これはすべて問題です。開始する前に、できるプロセスを強制終了します。いくつかのことができるベンチマークライブラリを使用してください。 https://github.com/google/caliper などが好きです。
システムベンチマーク
現実的なワークロードの下でシステムのベンチマークを行う場合、これらの詳細は実際には興味がなく、問題は「のみ」です。現実的なワークロードとは何か、それを生成する方法、収集するデータを知るため。本番システムをインスツルメントし、そこでデータを収集できる場合は常に最適です。エンドユーザーの特性(Webページのレンダリングにかかった時間)を測定し、データを収集するコードがシステムの速度を低下させないように、これらはI / Oバウンドであるため、通常はこれを行うことができます。 (ページはネットワーク経由でユーザーに出荷する必要があります。プロセスで数個の数値も記録するかどうかは関係ありません。)
プロファイリングとベンチマークの違いに注意してください。ベンチマークは何かをするのに絶対的な時間を与え、プロファイリングは何かをするのに必要な他のすべてと比較して相対的な時間を与えます。これは、プロファイラーが高度に計測されたプログラムを実行し(一般的な手法は、数百ミリ秒ごとに世界を停止し、スタックトレースを保存する)、計測によってすべてが著しく遅くなるためです。