背景と目的
前回は実運用に近い検証を目的に、ビューから取得する文書のサイズ（フィールド数）とビュー操作を行うメソッドの特定を測定しました。今回は、ビューに定義されている列数とレスポンスの関係について調査します。
測定環境
測定に使用する PC はこれまでと同じ PCを使用します。また、DB は前回作成したダミーフィールドを 200 個追加したものを使って測定します。
今回のテストでは、ビューに配置するダミーフィールドの数を変化させテストします。利用するビューは次の 5 種類です。
| View 名 | テスト文書の状態 |
| 000 | ダミー列なし。 |
| 050 | ダミー列を 50 個追加（Text_00 ～ Text_31） |
| 100 | ダミー列を 100 個追加（Text_00 ～ Text_63） |
| 150 | ダミー列を 150 個追加（Text_00 ～ Text_95） |
| 200 | ダミー列を 200 個追加（Text_00 ～ Text_C7） |
手順
測定手順はこれまでと全く同じとします。ビューに対して 20 回の検索を行い、取得したコレクションからエントリと値を取得する操作を 50 回行います。測定回数は 10 回です。
この測定を View 050 ～ 200 まで順に行います（View 000 については前回の結果を流用）。
なお、テスト項目と測定の項目は「#1）ビュー操作 ① - 測定方法」をご確認ください。
結果
測定結果は次の通りでした。
このままではわかりにくいので、測定時間の推移をテスト項目ごとにグラフ化します。
結果が水平となっているのは、D2、D3、E4、E5 です。それ以外のテスト項目については、列数に比例して処理時間が増えているように見えます。
前回に倣って、値の取得（D1 ～ D3、E1 ～ E3 ）に絞ってグラフ化ました。全体の処理時間（折れ線グラフ）も、列数にほぼ比例して処理時間が増えています。また、列数の増加に比例して、GetAllEntriesByKey の方が遅くなっていることが確認できます。
考察
今回の測定結果より推察できるビュー操作の特徴を整理します。
◇ 検索時間の違いはコレクション作成時間？
まず、ビューを検索し検索結果のコレクションを確認する D1 と E1 を比較します。処理時間の比率を確認するとダミー列なしで 1.7 倍、200 個で 1.6 倍の差があり、グラフ化すると次の通りでした。
D1 と E1 の測定では、検索キーの指定、検索結果が同じなので、ビュー検索時間は一定と仮定できると思います。グラフはほぼ水平であることから、コレクション作成時間は、ビューの列数に比例しており、列数が増えるほど GetAllEntriesByKey には不利に働くといえます。
◇ NotesViewEntry クラスのオーバヘッド
E2 の NotesViewEntry 取得の結果を見るとダミー列数に比例して、処理時間が増えています。D2 の NotesDocument の取得はダミー列数に依存せず一定な上、ほぼ 0 なので、エントリ取得という点においても、GetAllEntriesByKey が不利といえます。
◇ 列数の調整で逆転はない
前回のテストで、NotesDocument から値を取得すると文書サイズに比例して遅くなる結果が出ました。今回のテストはその特性が顕著に表れるダミーフィールド 200 個のテストデータで行いました。
ところが、上記 2 点のとおり、検索処理自体に加え、検索結果からエントリを取得する処理でも、列数に比例してコストが発生することがわかりました。
NotesViewEntry??? クラスを使用したオーバヘッドを赤の斜線、NotesDocument 使用時のオーバヘッドを青の斜線で表すと次のようになります。
最も有利なダミー列なしでも赤の部分があまりに大きく、列を増やすにつれてその差が開きます。この結果より、今回のテストケースにおいては、ビューの列数の調整で GetAllEntriesByKey が早くなることはないことがわかります。
◇ ビュー索引を活用
アルゴリズムの評価ではオーダ（Order）とい指標があります。これは、入力データ数に対して処理時間の変化するかを示すものです。
ソートを例にするとデータ数を n とすると、最悪で n2（n の 2 乗）、一般的には n log n の処理時間が必要なります。データがソート済みだった場合に限定すると n となるパターンがあります。オーダ n は、データ件数と処理時間が比例の関係になることを示します。一方、n log n や n2 は、データ件数の増加に従い急激に処理時間が増加します。
今回のテストでは、ビューの列数に依存する D1、E1、E2 はほぼ比例の関係になっています。この結果から、今回テストしたメソッドには、実行時にソート処理を行うような要素は含まれていないと推察できます。
よって、今回テストした処理では、すでにソート済みの索引データを順になぞっているだけであり、比例的な特性（オーダ n）になっていると考えられます
ビューの検索処理が、ビュー索引を活用した構造になっていることの一つの証左と言えますね。
まとめ
前回の検証では、
- 文書から値を取得する処理は、フィールド数に比例して遅くなる
- ビューからの値取得では、文書内のフィールド数に依存せず一定
今回の検証では、ビューに必要な列を用意すれば GetAllEntriesByKey の方が早くなる可能性を調査したのですが、結果は、
- ビューの列数とレスポンスは比例の関係
- NotesViewEntry??? の処理コストがあまりも高い
ことがわかり、優位に立つことはない結果となりました。
ただ、前回、今回の検証では、検索結果（コレクションのサイズ）を 1000 としていました。実運用では、少々大きすぎるかもしれません。コレクションを小さくした場合や GetEntryByKey ではどうなるかの検証が必要かもしれませんね。
| 前回 | Domino 体力測定 |
0 件のコメント:
コメントを投稿