Single Copy Templateの仕組 -2-
＜話題の履歴＞
前回は、TechnoteやIBM Siteの情報の提供に終わってしまいました。
今回以降では、Single Copy Template(SCT)の仕組みについて詳細に調べていく訳ですが、まず大事なことは、SCTが登場する前の仕組みも理解しておくことです。
今回はSCTの説明をする前提として、ClientのDesign Cacheの仕組みなどを解説したいと思います。
皆さん、Notes/DominoはClient/Serverで動いていて、設計の殆どの要素がClient側で処理されていることはご存知のハズです。
また、設計が変更されなければ、Client Cacheに保持した設計を利用しているということもご存知でしょう。
このように、Notes/DominoはLocalのCache(Cache.dsk/Cache.ndk)に設計をCacheして再利用するこことはこれまでにも述べたと思います。
毎回設計要素を読み込むようなことをすると、Mail DBのような複雑な設計の場合はPerformanceに影響を与えるからです。
別に複雑な設計でなくても、Networkが貧弱な環境では毎回設計要素を読み込むような処理をしていたのではPerformanceは良くはなりません。
流石、この辺はServerもNetworkも貧弱な頃に最適なPerformanceが保てるように設計されたNotes/Dominoのうまい仕組みだと思います。
皆さんもご存知のようにDesign Cacheの動きは基本的に以下のようになります。
Notes Clientで始めてDBにAccessすると、NRPC Commandで設計要素を要求し、その設計要素はCacheに格納されて利用されます。
2回目にAccessした際は、設計要素の更新がされていないかをCheckして、更新されていなければ、Cacheにある設計要素をそのまま利用し、毎回設計要素を読み込むようなことは行わないように出来ているのです。
また、これはReplica DBの場合も同じで、同じ設計であると判断されると、CacheにはEntryを生成して同じであることを示すだけで、設計を二重にCacheするようなことはないのです。
実際にこの動きを見ることは非常に簡単です。
またかと言われそうですが、NRPC Traceを取ることで動きを見ることができるのです。
単純化するために「Notes/Dominoの未読文書管理の仕組」で作成した一つのFormと1つのViewから構成されるDBで試してみると、その動きを見ることができます。
試す前に、Cache(Cache.dsk/Cache.ndk)と、念の為にBookmark(Bookmark.nsf)を削除します。
Bookmark.nsfを削除するのは、R4.xやR5の頃はCacheだけに情報を保持していたのですが、Notes 6以降ではBookmarkも一部Cacheのような機能を持っているからです。
NRPC Traceの取得の設定を行い、DBを開いて文書を開いてみると以下のようなNRPC Traceが取得されます。
(12-54 [12]) OPEN_DB(CN=DomSrv/O=LotusSW!!Test\UnreadTest.nsf): (Connect to DomSrv/LotusSW: 10 ms) (Exch names: 0 ms)(Authenticate: 0 ms.)
(OPEN_SESSION: 0 ms) 0 ms. [134+290=424]
(13-54 [13]) ISDB2_RQST: 0 ms. [14+16=30]
(14-54 [14]) GET_UNREAD_NOTE_TABLE: 10 ms. [290+172=462]
(15-54 [15]) OPEN_NOTE(REP49257118:001FE135-NTFFFF0010,03000400): 0 ms. [48+1018=1066]
(16-54 [16]) OPEN_COLLECTION(REP49257118:001FE135-NT00000116,0040,4000):
(17-54 [17]) OPEN_DB(CN=DomSrv/O=LotusSW!!Test\UnreadTest.nsf): (Connect to DomSrv/LotusSW: 10 ms) (Exch names: 0 ms)(Authenticate: 10 ms.)
(OPEN_SESSION: 0 ms) 0 ms. [134+290=424]
(18-54 [18]) CLOSE_DB(REP49257118:001FE135): 0 ms. [14+0=14]
20 ms. [250+2588=2838]
(19-54 [19]) GET_NOTE_INFO: 0 ms. [18+102=120]
(20-54 [20]) GET_COLLATION: 0 ms. [12+14=26]
(21-54 [21]) READ_ENTRIES(REP49257118:001FE135-NT00000116): 0 ms. [76+1726=1802]
(22-58 [22]) OPEN_NOTE(REP49257118:001FE135-NT000008F6,02400136): 10 ms. [48+458=506]
(23-58 [23]) OPEN_NOTE(REP49257118:001FE135-NT00000136,02400114): 0 ms. [48+2302=2350]
(24-61 [24]) CLOSE_COLLECTION(REP49257118:001FE135-NT00000116): 0 ms. [12+0=12]
(25-61 [25]) CLOSE_DB(REP49257118:001FE135): 0 ms. [14+0=14]
このTraceで黄色で示した部分が設計関係となり、最初は特別な設計要素、2番目がView Collection、3番目がFormとなっています。
このように、設計要素はNoteIDで判断することができるのです。
この後、Cacheの内容を見てみると、以下のようにCacheにEntryが作成されたことが確認できます。
Cacheの内容は、Notes Clientで直接Cache(Cache.dsk/Cache.ndk)を開いて確認することもできますが、Notes Clientで確認した場合は当然Cacheの文書を開くことはできません。
Notes Clientで見る場合は、ByURL Viewを使うと、Notes://形式でListされますので、DBのReplica IDが分かっていれば、どのDBのCache Entryなのかを判断できます。
また、ここで文書のPropertyを確認すると、$Title Fieldに設計要素の名前、$SourceDBPathにDBのあるServer名とFile Path、$SourceURLにReplicaIDとUNID/NoteIDによる設計要素のURL Path、$SourceSeqTimeに設計要素の最終更新日、$SourceSequenceに設計要素の改変Sequence No、$ClassNameに設計要素の種類(Formなど)というように保持していることが確認できます。
以前紹介したNotesPeekで見ると、以下のようになり、設計要素の判断はしにくいのですが、内容を一覧で見ることが可能です。
ここで、NRPC TraceのOpenNote Commandに記載されたNoteIDで探していくと、どの設計要素をDBを開く際に取得してCacheしているかが容易に分かるのです。
今回の場合は単純な設計ですので、ViewとFormをCacheしていることがわかります。
もう一度DBを開いて文書を開いた時のNRPC Traceは以下のようになります。
(26-139 [26]) OPEN_DB(CN=DomSrv/O=LotusSW!!Test\UnreadTest.nsf): 0 ms. [134+290=424]
(27-139 [27]) ISDB2_RQST: 0 ms. [14+16=30]
(28-139 [28]) GET_UNREAD_NOTE_TABLE: 10 ms. [290+172=462]
(29-139 [29]) OPEN_NOTE(REP49257118:001FE135-NTFFFF0010,03000400): 0 ms. [48+1018=1066]
(30-139 [30]) OPEN_COLLECTION(REP49257118:001FE135-NT00000116,0040,4000): 0 ms. [250+2588=2838]
(31-139 [31]) GET_NOTE_INFO: 0 ms. [18+102=120]
(32-139 [32]) GET_COLLATION: 0 ms. [12+14=26]
(33-139 [33]) READ_ENTRIES(REP49257118:001FE135-NT00000116): 0 ms. [76+1726=1802]
(34-141 [34]) OPEN_NOTE(REP49257118:001FE135-NT000008F6,02400136): 0 ms. [48+458=506]
(35-145 [35]) CLOSE_COLLECTION(REP49257118:001FE135-NT00000116): 10 ms. [12+0=12]
(36-145 [36]) CLOSE_DB(REP49257118:001FE135): 10 ms. [14+0=14]
ここでお分かり頂けるように、DBの特別な設計要素とView CollectionはOpenNote/OpenCollectionで設計要素を取得するNRPC Commandが発行されますが、Formの設計を取得するNRPC Commandは発行されなくなります。
最初の設計要素というのは特殊な設計要素で、この設計要素はCacheされず毎回読み込まれます。
また、View Collectionも毎回読み込まれるようになっています。
今回の場合は、それ以外の設計要素はFormだけしかありませんので、Formの読み込みが省略された形となっていますが、Mail DBなどの場合はFramesetやPage,Subformなどたくさんの設計要素がありますが、これらの設計要素はCacheされCacheが有効な限り再度読み込みされることはなくなるのです。
つまり、ServerのDBの設計要素が変更されていなければ、Cacheにある設計要素をそのまま利用するようにできている事がわかります。
尚、Cacheに保存される設計要素はServerに配置されたDBの物だけであり、Local DBの設計要素は保存されません。
Localの場合、わざわざCacheしなくてもDBから設計要素を取得すればよいからです。
次に、ServerのDBのForm設計を変更して、同様にNRPC Traceを取得すると以下のようになります。
(101-3455 [101]) OPEN_DB(CN=DomSrv/O=LotusSW!!Test\UnreadTest.nsf): 0 ms. [134+290=424]
(102-3455 [102]) ISDB2_RQST: 0 ms. [14+16=30]
(103-3455 [103]) GET_UNREAD_NOTE_TABLE: 0 ms. [290+172=462]
(104-3455 [104]) OPEN_NOTE(REP49257118:001FE135-NTFFFF0010,03000400): 0 ms. [48+1018=1066]
(105-3455 [105]) OPEN_COLLECTION(REP49257118:001FE135-NT00000116,0040,4000): 0 ms. [250+2588=2838]
(106-3455 [106]) GET_NOTE_INFO: 0 ms. [18+102=120]
(107-3455 [107]) GET_COLLATION: 0 ms. [12+14=26]
(108-3455 [108]) READ_ENTRIES(REP49257118:001FE135-NT00000116): 20 ms. [76+1726=1802]
(109-3460 [109]) OPEN_NOTE(REP49257118:001FE135-NT000008F6,02400136): 0 ms. [48+458=506]
(110-3460 [110]) OPEN_NOTE(REP49257118:001FE135-NT00000136,02400114): 0 ms. [48+2302=2350]
(111-3472 [111]) CLOSE_COLLECTION(REP49257118:001FE135-NT00000116): 0 ms. [12+0=12]
(112-3472 [112]) CLOSE_DB(REP49257118:001FE135): 0 ms. [14+0=14]
設計変更されたForm設計要素をNRPC Commandで再度取得していることがご理解いただけるでしょう。
また、Cacheの内容を確認すると、以下のように、CacheされたFormのSequenceとSequence Timeが変更されていることが確認できます。
このように、Notes ClientはLocal Cacheをうまく活用して、ServerとのNetwork Trafficを少なくし、Performanceを上げるようにできているのです。
今回は、設計のCacheについてNRPC Traceを使って見てみました。
次回は、別のServerにReplica DBがあった場合の動きについて解説します。