[Notes/Domino] 文書の読込速度低下の原因について
ノーツクライアントで文書を開く際に、文書サイズはたいして大きくないのに読込速度が遅い、という場合があるかと思います。原因については様々なものがあり、全てを記述することはできませんが、代表的なものと、その回避策をご紹介します。
ちなみに、ビューについては、以前にエントリした「ビューの速度低下の原因について」をご参照ください。
@DbLookup、@DbColumnが多い場合
これはよく知られているかと思いますが、@DbLookup、@DbColumn を多く記述しすぎると、読込速度が低下します。特にサーバー上にある他のDBから値を取る場合は、当然のことながらDBオープンやら通信やらが発生するので、遅くなります。
対策としては、それほど頻繁にデータが更新されない値を取得する場合で、「NoCache」オプションが指定されている場合は、「Cache」や「ReCache」に変更することで、速くなります。また、@DbLookup などの個数によっては、スクリプトで記述したほうが速くなる場合もあります。(単発なら、スクリプトより @DbLookup のほうが高速らしいですが。)
ただし、根本的な対策としては、やはり @DbLookup、@DbColumn の個数を減らすことが肝要です。たとえば、参照する値を以下のような形式(改行区切りの複数値)で保存しておき、
"TagA: 1つめの値" "TagB: 2つめの値" "TagC: 3つめの値" ・ ・ ・
以下のような式で取得すれば、
ret := @DbLookup(~略~); @Trim(@Right(ret; "TagB: "))
1回の @DbLookup の戻り値から、任意の値が取り出せます。(上記例では「2つめの値」が返ります。@Right はデリミタが見つからない場合はNULLになりますので、NULLになったところを @Trim で削除する、というわけです。)
ただし、参照先の値に改行が入っているとおかしくなってしまいますので、参照先のほうでエラーチェックをかけたり、改行を削除したりして、複数値を作る必要はあります。また、リストのサイズが大きくなると @DbLookup が失敗してしまいますので、注意してください。
フィールドが多い場合
フィールドが多すぎる場合、読込速度は顕著に遅くなります。この場合、以下の対策が有効です。
- 表の行が多いような場合は、改行区切りの複数値フィールドを各列1つだけ配置する。(見づらい場合は、縞模様の画像をセルの背景にして、行ごとに色分けするという荒技もあります(^^; 拡大フォントやWindowsのフォントサイズを変更しているユーザーがいる場合はダメですが。あと、長い文言がある場合も、折り返されてしまうのでNG。)
- 表示する必要がなければ、フィールドを削除する。(常にバックエンドで値をセットする。)
- 値を編集または参照する必要が無いものであれば計算結果テキストに変更する。(計算結果テキストは、バージョンによって文字のコピーができない場合がありますので注意してください。)
フィールドが多すぎる場合は、基本的には表示されるフィールドを減らすしかありません。減らした上で、たとえばフォームにボタンを配置して、ボタンをクリックするとサブフォームをダイアログとして表示し、本来フォームに表示されるはずのフィールドを表示させる、というのも1つの手です。ボタンをクリックする手間がありますが、読込速度が分散されるので、速くなったかのように見せかけることができます。
読込専用&動的変更が必要無い表であれば、パススルーHTMLを使ってみるのもよいかもしれません。ただし、巨大な表は作れないので、巨大になる場合は適度に分割する必要があります。
また、可能であれば、フォームを分割して同じ文書をフォームを切り替えてみせる、とか、いくつかのサブフォームに分けて条件によって必要なサブフォームだけ表示する、という方法も有効です。ただ、擬似的なタブインタフェースのようなものを作ろうとすると、かなり面倒ではありますが。
そもそもフィールドの数が多い場合、文書の上限値を超える場合もあります。その場合は、Summaryフラグをオフにする必要も出てきます。そちらについては、以前にエントリした「Summaryフラグに関するあれこれ」を参照してください。
サブフォームが多い場合
サブフォームが多い場合に遅くなるという現象があります。このケースでは、「Initialize に Print 文を入れれば直る」とリンク先に書いてあります(未検証)。
文字が多い場合
フォームに記述された文章が長い場合、読込速度が低下する場合があります。こちらは、以前にエントリした「長い文章をフォームに設定していると、文書を開く速度が遅くなる」を参照してください。
パススルーHTMLが多い場合
最近さんざんパススルーHTMLをプッシュしてきましたが、あまりに多く使いすぎると遅くなるようです。特に低速な回線で顕著に遅くなります。
原因は、パススルーHTML 1 つにつき「GET_SERVER_STATS」(NSFGetServerStats)が2回発行され、サーバーとの通信が発生するためです。パススルーHTMLの中身が無くても、非表示であっても、関係なく発行されるようです。なんでこんなものが発行されるのかよく解りませんが、使いすぎは禁物ということで。(10~20個くらいなら問題ないでしょう。)
原因の見当がつかない場合
速度低下の原因は多岐に渡ります。原因の見当もつかない場合は、おとなしくDBをコピーして、1つずつ疑わしい設計を削除していってどこがボトルネックになっているかを洗い出すのがよいと思います。急がば回れということで。
また、速度低下の原因を調査するのに威力を発揮するのは、NRPCのログを取得することです。以前にエントリした「@UserAccess は速度が低下する場合がある」では、NRPCログが大活躍でした。詳細については、岩間さんのブログをご覧ください(また丸投げ)。
いろいろと手段を尽くしても解らない場合は、バグの可能性もあるかもしれません。その場合はサポート情報を検索することをお勧めします。
コメント
コメントはありません
※コメントは承認制となっております。管理者が承認するまで表示されません。申し訳ありませんが、投稿が表示されるまでしばらくお待ちください。