Domino 体力測定：#5）ビュー操作 ⑤ - ハードウェアパフォーマンスとの関係

しばらく間が空いてしまいましたが、これまで４回にわたり GetAllDocumentsByKey と GetAllEntriesByKey の速度比較を行ってきました。検証のテーマは、

	テーマ
#2	一般的な環境（SSD）での基本挙動確認
#3	文書サイズと検索/値取得の特性
#4	ビューの列数と検索/値取得の特性

でした。結果はいずれも GetAllDocumentsByKey が高速であるという結論でした。

連載のきっかけとなった 訂正記事 に挙げたパフォーマンスに影響を与える要因を順番に検証し、GetAllEntriesByKey が早くなるパターンを探してきました。今回は、複数の PC を使用して、CPUやメモリ、ストレージの I/O が与える影響について観察します。

本来であれば別々に観察すべきですが、個人的に用意できるリソースには限りがありますので、おおざっぱなテストになります。予めご了承ください。

検証環境

今回の検証で使用する PC は以下の 3 台で、構成は次の通りです。

	PC1	PC2	PC3
CPU	Ryzen 7 7900X	Ryzen 5 3600	Celeron G540
メモリ	128 GB	32 GB	2 GB
ストレージ	SSD	SSD	HDD
OS	Windows 11	Windows 10	Windows 10

検証に当たり、各 PC のベンチマークを行いました。主な項目と測定結果の画像は次の通りです。

	PC1	PC2	PC3
All	26,123	11,522	756
CPU	17,564	7,065	3842
ランダムリード	713	590	6
ベンチマーク結果

テスト項目と手順

テスト項目はこれまでと同じです。GetAllEntriesByKey では、ビューから値を取得するだけなら 1 ～ 3、文書フィールドにアクセスするなら 1、２、4、5 の合計時間となり、GetAllDocumentsByKey と比較できます。

	検証項目	D）GetAllDocumentsByKey	E）GetAllEntriesByKey
1	コレクション作成	GetAllDocumentsByKey で検索し、コレクションを取得	GetAllEntriesByKey で検索し、コレクションを取得
2	エントリ取得	GetFirstDocument、GetNextDocument で文書を取得	GetFirstEntry、GetNextEntry でエントリを取得
3	値の取得	文書から値を取得	ColumnValues で値を取得
4	文書の取得	－	Document プロパティで文書を取得
5	文書から値の取得	－	文書から値を取得

測定する DB はこれまでのものを流用します。100 Byte のダミーフィールドを 200 個追加した文書（#3 で紹介）を列数の違うビュー（000 と 200）で検索します。000 はダミーフィールドなしの軽いビュー。200 はすべてのダミーフィールドを列に追加した重いビューをイメージしています（#4 で紹介）。

測定手順も同じです。ビューに対して 20 回の検索を行い、取得したコレクションからエントリと値を順に取得する操作を 50 回行います。測定回数は 10 回としますが、PC3 はあまりに遅いため 3 回としました。

結果

測定した結果をグラフに表すと次の通りです。

（図 #5-1）

縦軸をそろえたグラフは次の通りです。

（図 #5-2）

考察

◇ 基本特性の変化

図 #5-1 を確認します。

上段（軽いビュー）の結果を比較すると PC1、2 に比べ PC3 でその差が幾分詰まっています。貧弱なリソース環境においては GetAllEntriesByKey の方が効率的に動くように設計されているのかもしれません。

下段の重いビューでは、処理の比率に変化は見られません。ビューの列が増えることで、効率の良さを打ち消しているのではないかと想定できます。

どちらの検証結果についても GetAllDocumentsByKey が優位であることには変わりがなく、GetAllEntriesByKey が逆転することはありませんし、その気配すら感じません。

◇ リソースの確保は重要

図 #5-2 では縦軸をそろえているので、絶対的なレスポンスがわかります。

最も時間を要している処理１を使って比較します。PC1 の処理時間を基準にすると次のような差（単位：倍）となりました。

環境	View = 000	View = 200
PC2	2.48	2.30
PC3	11.58	64.77

PC3 ではストレージが HDD であることに加え、CPU やメモリも貧弱です。これが原因で、テスト時にはスラッシングが発生していたと推察できます。これが原因となり PC2 に比べ異常ともいえるパフォーマンスの劣化が発生したと考えられます。リソース確保の重要性がよくわかる結果ですね。

まとめと今後の進め方

PC3 の View = 200 のテストはスラッシングが発生し、スペック以上に能力が低下していたと推察しました。ということは、さらに昔の世代のテストができたのかもしれません。しかし、この状況においても GetAllDocumentsByKey が優位であることには変わりがありませんでした。本当に昔の常識とされた GetAllEntriesByKey 優位というシナリオは存在するのでしょうか？

残された可能性は ODS ぐらいですかね。最近の ODS では GetAllDocumentsByKey に対する最適化が進み、逆転するシナリオが存在しないという可能性です。ODS については腰を据えて、検証してみたいと思っていたので、別途検証したいと思います。よい結果が出れば、塩漬けされた Domino サーバをバージョンアップする理由になるかもしれませんね。

これまでの『Domino 体力測定』は、きっかけとなった 過去の神話 を検証する方向で進めてきました。明確な答えが出ないまま方向転換するのは残念なのですが、過去を振り返るより将来にわたって ”使える” 検証に時間を割きたいと思います。

今後 ODS の評価以外にも、NotesDocumentCollection クラスの GetNextDocument と GetNthDocument の比較など、複数の手法がある開発を題材に比較してみたいと思います。

前回

Domino 体力測定