あるタイプのデータベース・ベンチマークでは、 構成パラメーターを選択し、最大の効果を得るまで、 そのパラメーターに異なるさまざまな値を使ってテストを実行します。 単一テストでは、 同じパラメーター値を使ってアプリケーションを何度か繰り返して (たとえば 10 回) 実行するようにし、 平均時間を調べます。 これにより、パラメーター変更の効果をよりよく知ることができます。
ベンチマークを実行するときは、最初の繰り返し (ウォームアップ実行) を、 後続の繰り返し (通常実行) とは別個のケースであるとみなすようにします。 これが必要なのは、ウォームアップ実行の結果には、 いくつかの起動活動 (バッファー・プールの初期設定など) が含まれるためです。 このため、ウォームアップ実行は、通常実行より多少長くかかります。 ウォームアップ実行から得られる情報は、 現実的に有効である可能性はあります が、 統計的には無効なものです。 したがって、パラメーター値の特定の集合に関して平均時間や CPU を計算するときは、 通常実行の結果を使用してください。
ベンチマークのウォームアップ実行を作成するために 「パフォーマンス構成 (Performance Configuration)」ウィザードを使用することができます。 「パフォーマンス構成 (Performance Configuration)」ウィザードの一部として尋ねられる質問に応答することによって、 ベンチマーク作業の通常実行において、 環境の構成を調整するときに考慮すべき内容について考えることができます。 「パフォーマンス構成 (Performance Configuration)」ウィザードを使用するためには、 db2cc を入力してコントロール・センターに入り、そこから進みます。
個々の照会を使用してベンチマークを行っている場合は、 直前の照会の影響が最小になっていることを確認する必要があります。 バッファー・プールをフラッシュするとこの状態になります。 つまり、(照会とは無関係な) 多数のページを読み取ってバッファー・プールに入れるということを行います。
パラメーター値の単一の集合での繰り返しを完了したら、 単一のパラメーターを変更することができます。 しかし、繰り返しから次の繰り返しまでの間に、以下に示すタスクを実行して、 ベンチマーク環境がその元の状態に復元されるようにしてください。
以下は、OS/2 上でベンチマーク・テストを行うための追加の考慮事項です。
ベンチマーク・プログラムからの出力には、各テストの識別子、 プログラム実行の繰り返し回数、ステートメント番号、 および実行時間が含まれるようにします。 一連の測定の後ベンチマーク結果の要約は、次のように表示されます。
Test Iter. Stmt Timing SQL Statement Numbr Numbr Numbr (hh:mm:ss.ss) 002 05 01 00:00:01.34 CONNECT TO SAMPLE 002 05 10 00:02:08.15 OPEN cursor_01 002 05 15 00:00:00.24 FETCH cursor_01 002 05 15 00:00:00.23 FETCH cursor_01 002 05 15 00:00:00.28 FETCH cursor_01 002 05 15 00:00:00.21 FETCH cursor_01 002 05 15 00:00:00.20 FETCH cursor_01 002 05 15 00:00:00.22 FETCH cursor_01 002 05 15 00:00:00.22 FETCH cursor_01 002 05 20 00:00:00.84 CLOSE cursor_01 002 05 99 00:00:00.03 CONNECT RESET |
注: | 上記レポートのデータは、例示目的でのみ示したものです。 測定された結果を表すものではありません。 |
このレポートのデータを調べると、CONNECT (ステートメント 01) に 1.34 秒、 OPEN CURSOR (ステートメント 10) に 2 分 8.15 秒かかり、 FETCHES (ステートメント 15) は 7 行を戻してその最大の遅延が .28 秒で、 CLOSE CURSOR (ステートメント 20) に .84 秒、 および CONNECT RESET (ステートメント 99) に .03 秒かかっていることが分かります。
区切り付き ASCII 形式でデータを出力すると、 後でそれを統計分析の目的でデータベース表やスプレッドシートにインポートするのに便利です。
ベンチマーク・レポートのサンプル出力は、次のようになります。
PARAMETER VALUES FOR EACH BENCHMARK TEST TEST NUMBER 001 002 003 004 005 locklist 63 63 63 63 63 >> buffpage 1000 1175 1250 1325 1400 << maxappls 8 8 8 8 8 applheapsz 48 48 48 48 48 dbheap 128 128 128 128 128 sortheap 256 256 256 256 256 maxlocks 22 22 22 22 22 stmtheap 1024 1024 1024 1024 1024 SQL STMT AVERAGE TIMINGS (seconds) 01 01.34 01.34 01.35 01.35 01.36 10 02.15 02.00 01.55 01.24 01.00 15 00.22 00.22 00.22 00.22 00.22 20 00.84 00.84 00.84 00.84 00.84 99 00.03 00.03 00.03 00.03 00.03 |
注: | 上記レポートのデータは、例示目的でのみ示したものです。 測定された結果を表すものではありません。 |
この例のデータを調べると、 buffpage パラメーターの変更によって OPEN CURSOR の時間が 2.15 秒から 1.00 秒に連続的に低くなっていくことがわかります。 (前提として、バッファー・プールは 1 つ (1) だけで、 そのサイズ (NPAGES) は -1 に設定されています。 すなわち、バッファー・プールのサイズは、 buffpage パラメーターによって制御されます。)
まとめると、データベース・アプリケーションのベンチマークは、 次のステップまたは繰り返しを行います。
この初期ケースに関して一連の繰り返しを実行し、平均時間、または CPU を計算します。
注: | パフォーマンス結果をグラフ化する予定であれば、 曲線が上がり始めるかまたは下がり始める点を探すようにしてください。 |
ベンチマーク・テストのためのドライバー・プログラムを作成することもできます。 そのドライバー・プログラムは、REXX などの言語を使用して作成するか、 または UNIX ベースのプラットフォームの場合は、 シェル・スクリプトを使用して作成できます。
このドライバー・プログラムはベンチマーク・プログラムを実行し、 プログラムに適切なパラメーターを渡し、テストを複数回繰り返し、 環境を一貫した状態に復元し、新しいパラメーター値を使って次のテストを設定し、 さらにテスト結果を収集 / 統合します。 これらのドライバー・プログラムは非常に柔軟性に富んでおり、 一連のベンチマーク・テスト全体を実行し、結果を分析してから、 さらに所定のテストの最終パラメーター値および最適パラメーター値のレポートを作成する、 といったことも可能です。