背景と目的
前回はビュー操作を行う 2 つのメソッドの基本的な特性の測定結果を紹介しました。そのテストでは、テストデータの文書は小さく軽量、検索用のビューもシンプルでした。より実運用に近い検証となるよう、追加でテストしたいと思います。
今回はフィールド数を変化させ、レスポンスにどのような影響があるのか測定します。
測定環境
まず、測定に使用する PC は前回と同じものを使用します。SSD 搭載の今どきの環境の想定です。
フィールド数とレスポンスの関係を調べることから、今回のテスト DB は、一定のダミーフィールドの個数を変化させた5 種類を用意します。ダミーフィールドには、読み込み用と同じ 100 Byte のテストを設定します。
| DB 名 | テスト文書の状態 | 文書サイズ |
| 000 | 前回と同じ。 | 188 Byte |
| 050 | 000 の文書にダミーフィールドを 50 個追加（Text_00 ～ Text_31） | 5288 Byte |
| 100 | 000 の文書にダミーフィールドを 100 個追加（Text_00 ～ Text_63） | 10388Byte |
| 150 | 000 の文書にダミーフィールドを 150 個追加（Text_00 ～ Text_95） | 15488Byte |
| 200 | 000 の文書にダミーフィールドを 200 個追加（Text_00 ～ Text_C7） | 20588Byte |
参考までですが、ダミーフィールド作成する部分のコードは次の通りです。
| '取得用の値 s = Right("0000000000" & s, 10) s = s & s & s & s & s & s & s & s & s & s Call nd.Replaceitemvalue("Text", s) 'ダミーフィールド作成（viWait は作成する個数） For i = 0 To viWait - 1 Call nd.Replaceitemvalue("Text_" & Right("00" & Hex(i), 2), s) Next |
250 個作成しようとするとエラーとなりました。9.0.1 FP8 以降で対応した LargeSummary を有効化する必要があるので、今回は 200 個までで検証としています。
手順
測定手順は前回と全く同じです。ビューに対して 20 回の検索を行い、取得したコレクションからエントリと値を取得する操作を 50 回行います。測定回数も同じ 10 回とします。
この測定を DB 050 ～ 200 まで順に行います（DB 000 については前回の結果を流用）。
結果
測定結果は次の通りでした。
横軸を文書サイズに設定し、各測定項目と DB 毎の結果をグラフ化すると次の通りです。
D3、E5 のグラフは右肩上がりの直線となっており、フィールド数に比例しているといえます。それ以外のグラフは水平で、フィールド数の影響は受けないことがわかります。
考察
今回の測定結果より導くことができるビュー操作の特徴を整理します。
◇ ビュー検索はフィールド数に依存しない
ビューの検索を行う D1、E1 ともフィールド数増減の影響を受けず、ほぼ一定の処理時間となっています。また、コレクションからエントリを取得する処理（D2、E2）も同様です。さらに、NotesViewEntry から NotesDocument を取得する処理（E4）も一定です。
これらの結果より、コレクション、コレクション内のエントリ操作、NotesDocument オブジェクトの取得までは、文書単位で処理をしており、文書内のフィールド数には依存しないことがわかります。
ここまでの処理においては、1 文書は 1 文書で、その内部の状態は関係ないということですね。
◇ 値取得はフィールド数に依存
NotesDocument から値を取得する処理（D3、E5）では、フィールド数に比例して、処理時間が増加します。
今回の検証データは、読み込む Text フィールド作成後、ダミーフィールドを追加しました。内部的に作成順で記録されていると仮定すると、Text フィールドは文書のほぼ先頭に存在します。それでも、フィールド数に比例した結果になるということは、フィールドにアクセスしたタイミングで、すべてのフィールドの一覧を作成していると考えられます。
アプリの仕様変更を行うと無用となるフィールドが発生することがあります。実害がないので、ついつい残しがちなのですが、パフォーマンスという観点でいうと削除しておいた方がよさそうですね。
なお、今回の検証では、ダミーフィールドのサイズを固定したため、フィールド数 ≒ 文書サイズとなっています。今回の特性の要因が、文書サイズである可能性が残ります。
◇ 逆転の可能性
文書から値を取得することだけに限定すると、D1 ～ D3、E1 ～ E3 までで実現できます。この部分に絞って、結果を整理すると次のようになります。
GetAllDocumentsByKey（青）のグラフは右肩上がりで、GetAllEntriesByKey（オレンジ）は水平です。ダミーフィールドなしでは、ほぼダブルスコアですが、200 個ではずいぶん差が小さくなっています。さらにフィールドを増やしたテストを行えば逆転することがあるかもしれません。
なお、今回の検証では、ダミーフィールドのサイズを 100 バイトにしています。そのため 200 個以上フィールドを増やせませんでした（Summary フィールドの上限）。セットする値を小さくし、フィールド数を増やした場合や Domino 9.0.1 FP8 以降で対応した LargeSummary 環境での特性も気になりますね...
まとめ
今回の検証では、GetAllEntriesByKey で検索し ColumnValues で値を取得する限りにおいては、フィールド数に依存せず同じレスポンスになることがわかりました。逆に NotesDocument オブジェクトを介して値を取得するとフィールド数に比例した処理時間が必要とります。ただ、ここまでの検証では GetAllEntriesByKey の方が早くなるパターンは見つかっておらず、GetAllDocumentsByKey が優勢の状態に変わりはありません。
なお、今回の検証で不明瞭な点は、次の通りです。機会があれば検証したいと思います。
- もっと大量のフィールドが存在する場合、処理時間が逆転することはあるか？
- フィールドサイズの大小で変化はあるか？
- LargeSummary 環境において特性に変化はあるか？
| 前回 | Domino 体力測定 |
0 件のコメント:
コメントを投稿