『Lotus Notes/Domino 7アプリケーションのパフォーマンス:第1部』では、データベース・プロパティーと文書コレクションを効率よく使用して、Lotus Notes/Domino 7アプリケーションのパフォーマンスを改善する方法について説明しました。第2部では、パフォーマンスの高いビューを作成する方法について説明します。第1部と同様に、この記事には、再利用や独自アプリケーションへの応用が可能なサンプル・コードが多数含まれています。

長年にわたってアプリケーションのパフォーマンスの問題を分析してきた結果、ビューは問題とソリューションの両方に頻繁に関わっていることがわかりました。ビューの索引作成は、しばしば問題となります。この記事では、これがどのように発生するのかを明らかにし、このような問題に対し、トラブルシューティングを実行し、解決するために何をすればよいのかを説明します。しかし、これ以外にも、過去数年にわたり頻繁に現れていたビューのパフォーマンスの問題があります。これは、読み込みアクセスが制御された文書を表示するビューに関係します。これらのビューでのパフォーマンスの問題は索引作成とは無関係のことが多いので、ここではそれぞれを別に取り上げます。

この記事は、Lotus Notes/Dominoアプリケーション開発者としての経験がある方を対象として書かれています。

ビューの索引作成(Updateタスク)を理解する

ビューの索引作成が関与するパフォーマンスの問題をトラブルシューティングする前に、まず、ビューの索引作成プロセスがどのように機能するかを理解する必要があります。通常、索引作成は、Lotus Domino Serverで15分おきに実行されるUpdateタスクによって行われます。技術的にはこの間隔を調整できますが、ファイル名の変更が必要なため、実際にはほとんど行われません。

実行されたUpdateタスクは、Updateタスクの最新の実行日時以降の更新日時を持つ各データベースをサーバー上で検索します。次に、このタスクは、これらのデータベース内のビューを更新します。これまでの経験によると、実稼働環境内の実動データベースでは、通常のビューの更新に約100ミリ秒かかると考えてよいでしょう。

ここで、「更新が必要なビューをどのように見分けるのか」という当然の疑問が浮かんできます。次のいずれかが発生するたびに、ビューの更新が必要となります。

• 複製によって文書の変更がデータベースに送信される
• ユーザーが文書を削除または保存する (そして、データベースを閉じる)
• ルーターが文書を配信する

Updateタスクは非常に画一的な方法で、ビューに更新が必要かどうかを判断します。たとえば、メール・ファイルで、メモの[BCC]フィールドだけを変更し、他は何も変更していないケースを考えてみましょう。このフィールドの内容はどのビューにも表示されないため、ビューを更新する必要はありません。それにもかかわらず、このメモを含むビューは少なくとも調べられます。ユーザーが加えた編集によってビューが変更されるかどうかをサーバーが判断できないからです。

考慮しなければならい点は他にもあります。ユーザーが、ビューを開いたりビュー内で文書を変更すると、優先度の高い要求によってビューはすぐに強制的に更新されます。例を使用して考えてみましょう。

たとえば、Aliceが9:02AMに[連絡先管理]データベースのビュー#1を開いたとします。便宜上、Updateタスクは9:00:00に実行され、それ以降は9:15:00、9:30:00、・・・という時刻に実行されるものとします。Aliceは9:05AMに複数の文書を更新しました。彼女は、新規文書を作成し、既存の文書を編集し、文書を削除した可能性があります。どのようなケースでも、彼女はこのビューで作業しているため、サーバーはビュー#1を直ちに更新します。もし、文書を削除したのに、その文書がまだビューに表示されていると奇妙なことになります。このため、ビューはすぐに更新されます。しかし、他のビューは9:15AMの更新に向けてキューに登録されます。

そこで、Bobも9:02AMに[連絡先管理]データベースを開いていることにします。彼はビュー#1で作業しています。9:05AMビューが更新されたことを示す青色の再ロード矢印が左上隅に表示されます。ここで、F9キーを押すか、再ロード矢印をクリックすると、更新された内容がビューに素早く表示されます。彼は、更新されるのを待つ必要がありません。

さらに、Cathyも9:02AMにこのデータベースを開いていることにします。ただし、ビュー#2で作業しています。彼女がこの間に更新を強制するような操作を行わないと (あまりないことですが、可能です)、9:15AMにUpdateタスクによってビューが更新され、青色の再ロード矢印が表示されますしかし、多くの場合、Cathyは自分自身でデータを更新したり、ビューのスクロールや切り替えを行います。これらのいずれの動作によっても、すぐに更新が強制的に実行されます。

9:15AM、これらのクライアントが強制的に更新しなかったビューが更新され、再び最初の状態に戻ります。

ビューの索引作成についての追加情報

役に立つ2つの情報について説明します。最初は、全文インデクサーです。一般に、直ちに更新するよう指定された全文索引は、数秒(サーバーがビジーの場合は数分)以内に更新されます。毎時の全文索引は、Updateタスクによって適切な間隔で更新(トリガー)されます。毎日の全文索引は、夜間に実行されるUpdallタスクによって更新(トリガー)されます。

2番目の追加情報は、開発者がビューの設計プロパティーで設定できる索引オプションについてです。多くの人々は、この設定がUpdateタスクまたはUpdallタスクの実行方法に影響するものと誤って理解しています。これは正しくありません。UpdateタスクとUpdallタスクはこれらの設定を完全に無視し、前の例で説明した条件だけに基づいてビューを更新します。

索引オプションは、クライアントがビューを開いたときの動作について影響を与えます。たとえば、オプションが[手動]に設定されている場合は、ビューの内容が非常に素早くユーザーに表示されます(内容が古い可能性もあります)。オプションが[自動(周期)]に設定されていて、指定された間隔よりも時間が経過している場合は、あたかも、ビューの索引オプションが自動に設定された通常のビューであるかのように、ユーザーはビューが更新されるまで待たなければなりません。これらの索引オプションを使用して役に立つビューを作成する方法については、後述します。

ビューの索引作成のトラブルシューティングに関するクイック・ヒント

よく調整された環境では、索引作成は比較的意識されず、ビューと全文索引は素早く更新されます。パフォーマンスの問題がある環境では、次のような症状が見られます。

• データベースやビューを開いたり、ビューの切り替え、ビューのスクロール、文書の保存を行うときに、大きな遅延が生じます。
• 検索を使用する文書を開くときに遅延が生じます (実際に、検索の実行待ちで、フォームが停止することがあります)。
• 勤務時間帯はパフォーマンスに問題がありますが、オフ・タイムは優れたパフォーマンスとなります。
• 全文検索が期限切れとなります。

これらの問題を解決するには、次に示すログとデバッグ用のNotes.iniパラメーターを使用します。

ビューの索引作成の問題をトラブルシューティングするには、log_update=1を設定して (未設定の場合) log.nsfへのデータ収集を指示することから始め、ビューの更新に関する1日分の情報をサーバーで収集します。次に、log.nsfの[Miscellaneous Events]ビューでその日のデータを調べ、パターンを探します。出現する可能性がある重要なパターンは次のとおりです。

• 特定のデータベースで更新時間が非常に長い。これは、データベースで更新されるデータが多すぎる、複雑なビューが多すぎる、または日付/時刻に影響されるビューがある (サーバーがリリース5以前の場合) などのことを意味することがあります。次のステップとしては、ビジネスでの用途とデータベースの設計を調べます。また、1日間log_update=2を使用して、データベースのどのビューが問題になっているのかを絞り込むことも有効でしょう。
• 更新サイクルが非常に長い。サイクルが4〜5時間に及ぶケースもあります。この場合、Updateタスクは変更されたすべてのデータベースを15分ごとに処理せず、1日2、3回処理しているようです。これは、すべてのタスクに影響する全体的なパフォーマンスの問題か、サーバー上のデータ・ロードまたはユーザー・ロードが非常に高い可能性があります。次のステップとしては、サーバーの全般的な状態と、そのサーバーでのビジネス用途を調べることです。

更新時間が長いケースを発見した場合は、常に、同時に実行されている他のタスクは何か、それらのタスクは正常に実行されているかどうかを調べるとよいでしょう。また、索引の作成が遅くなるのは、全体的なものか、営業時間だけなのか、特定のピーク時間だけなのか(たとえば、2時間おきなど)を確認すると役に立ちます。1回の観察で問題の解決に必要なすべての情報を得られることは希ですが、通常、それは正しい方向を示しています。

ビューのパフォーマンスのテスト

さまざまな機能やビューの構築方法のパフォーマンスをテストするために、私たちは400,000文書を持つデータベースを作成し、4,000文書を更新するスケジュール済みエージェントを5分ごとに実行しました。次に、約20個のビューを構築しました。各ビューは少しずつ異なる機能を持ちますが、いずれも5つの列を使用して400,000文書すべてを表示するようになっています。詳細については後述しますが、全体の概要は次のとおりです。

• ビューのサイズは、そのビューを再構築および更新するために必要な時間と強く関連しています。ビューのサイズが2倍になると、そのビューを再構築または更新する時間も2倍になります。このため、100MBのデータベースがあり、このサイズが6カ月ごとに倍増することが予測される場合は、現在の索引作成の時間が30秒だとすると、索引作成の時間は6カ月後に60秒になり、さらにその6カ月後は120秒、というように増加することが予想されます。
• ビューの索引作成の観点から、最大の「パフォーマンス・キラー」となるのはカテゴリー化された列です。ソート列は、[索引にユニークなキーを作成する]オプションなどの他の機能と同様に少しのオーバーヘッドを追加します(これについては、記事の最後にあるヒントで説明します)。

図1と2は、サイズと更新時間の関係、およびカテゴリー化された列がビューのパフォーマンスに与える深刻なオーバーヘッドの両方を示します。図1は、ビューの索引サイズに対する応答時間を表したものです。

図2は、ビューのサイズと更新時間の関係を示します

どちらのグラフでも、最初と3番目のカテゴリー化されたビューは初期状態で展開されていて、2番目と4番目のビューは初期状態で省略されています。カテゴリー化されたビューを省略することは、短い時間であっても、確実に更新時間を短縮できます。

上に戻る

[読者]フィールド

過去数年間、[読者]フィールドとビューに関連する問題が急増しています。お客様は、一日のうちに何度も受け入れがたいパフォーマンスを経験することがあります。コードのレビューと事前のテストはすべて円滑に行われたので、なぜこのようなことが起こるのか理解できません。しかし、部署/部門/会社全体に配備した数カ月後、パフォーマンスに関する不満が社員間に広がり、何らかの対策が必要となります。

例

人事アプリケーションと営業アプリケーションを例にとって説明します。通常、どちらのアプリケーションでも、[読者]フィールドによる厳密な制御が行われています。次の表は、400,000文書を持つデータベースを使用している会社での仮想のシナリオを示します。

一般に、上級役員、Lotus Dominoのシステム管理者、および開発者は非常に優れたパフォーマンスを経験します。このため、パフォーマンスの低下に関する最初のレポートは無視されがちになります。通常、パフォーマンスの問題はより低い接続性能によって悪化するため (LANと比較した場合のWAN)、初期の不満が妥当ではないとみなされることもあります。しかし、苦情の件数がかなり増えると、担当者が社員と一緒にワークステーションの前に座り、データベースを開いたり、文書を保存するときにどれだけ長い時間がかかるかを知り、初めて問題の大きさが注目されます。400,000文書を持つサンプル・データベースでユーザーがビューを開くのにかかる時間を図3に示します。すべてのビューは、すでに更新されています。テスト・サーバーでは他のタスクは実行されておらず、一度に一人のユーザーだけがサーバーにアクセスします。

ユーザーは、表示できる文書数のパーセントで示されています。棒グラフが見えない場合は、非常にゼロに近い値であることを意味します。

[読者]フィールドとパフォーマンスの説明に移る前に、図3での注目点を1つ示しておきます。0.01%のユーザーと100%のユーザーを比較すると、階層なし (ソート済み、非カテゴリー化) のビューのユーザーが、アプリケーションのパフォーマンスに、なぜそのように大きな印象の違いを感じるのかがすぐにわかります。

[読者]フィールドを理解する

アプリケーションで[読者]フィールドが使用されているときは、すべての文書または一部の文書に[読者]フィールド、つまり要約の読み込みアクセス権を持つフィールドが含まれることを意味します。要約とは、データをビューに表示できることを意味します。技術的には、[読者]フィールドを作成し、そのフィールドが要約フラグを持たないように設定できますが、Lotus Dominoは文書のセキュリティーをビュー・レベルで適切に維持することができません。読み込みアクセス権限は、誰がこの文書を読めるのかを定義します。一般に、このようなフィールドでは、個人の名前、グループ名、[ロール]を指定します。メンテナンスと制御の理由から、できるだけグループよりも[ロール]を使用することお勧めしますが、パフォーマンスの観点からは、これらはすべて等価です。

読み込みアクセスが制御されたこれらの文書を含むビューをユーザーが開くとき、サーバーはこのユーザーに各文書の表示が許可されているかどうかを判断しなければなりません。サーバーは非常に機械的に一番上から順番に各文書をチェックします。このプロセスは次のようになります。

• Lotus Dominoは文書#1を調べ、ユーザーはそれを表示できると判断し、その文書を表示します。
• Lotus Dominoは文書#2を調べ、ユーザーはそれを表示できると判断し、その文書を表示します。
• Lotus Dominoは文書#3を調べ、ユーザーはそれを表示できないと判断し、その文書をユーザーに対して非表示にします。

このプロセスは、Lotus Dominoがビュー内のすべての文書を調べるまで続きます。もちろん、最初にビューを更新する必要があります。更新しないと、サーバーはどの文書が#1であるか、または[読者]フィールドの値が何であるかを認識できません。ここで、説明をいったん中断し、パフォーマンスが悪い典型的な例について考えましょう。[営業トラッキング]アプリケーションに[収益別]ビューがあり、このビューは契約金額の降順でソートされているものとします。ビューは5つの列で構成され、最初の2列 (たとえば、[収益]と[担当者]) がソートされています。カテゴリーはありません。このケースでは、ユーザーがビュー (400,000文書が表示される可能性があるビュー) を開くとき、このユーザーは最初にビューを強制的に更新します (必要な場合)。サーバーは、文書をユーザーに表示すべきかどうかのチェックを文書#1から開始し、文書#2、#3へとチェックを進めます。

読者の方は、おそらくWebブラウザーを使用してこの記事を読まれているでしょう。ご存じのように、Webブラウザーはページの一部 (テキスト) を素早くレンダリングし、それ以外の部分 (グラフィックなど) はよりゆっくりとレンダリングします。しかし、Lotus Domino Serverはこのような方法ではビューを表示しません。Lotus Domino Serverは、全画面の情報が揃うまでは、ビューの一部のデータをユーザーに送ることはありません。実際に、これは約60行分のデータとなっています。この動作は、Lotus Notes Clientで階層なしのビュー (カテゴリー化されていない列) を開き、下矢印キーを押すことによってテストできます。最初、ビューは素早くスクロールします。やがて、一時停止します。これは、サーバーが次の数KBのデータをユーザーのために用意している時間です。そして、ビューは再び次の約60行分を素早くスクロールします。矢印キーを押している間、この処理が繰り返されます。

ユーザーのケースに戻りましょう。このユーザーは文書#1を見ることができますが、次の10,000文書を見られないことがわかりました。なぜでしょうか。おそらく、このユーザーがデータベース全体で40文書しか見られないためです。Lotus Domino Serverは約60行分の情報を構築するまで (または、ビューの最後まで処理するまで)、ユーザーに何も表示しないので、待ち時間が長くなることがあります。

これは、まさにユーザーが経験することです。サーバーが各文書をチェックする間、ユーザーは何分も待つことがあります。ユーザーが表示できる文書が1画面に満たない場合でも、サーバーはビュー全体をチェックした後で、ユーザーに許可された文書、つまり画面の一部分だけのデータをユーザーに送ります。

この機能に気付いているユーザーもいます。また、現在、このことで苦労しているユーザーもいます。アプリケーションのパフォーマンスの問題を定期的に分析する方は、このような問題を迅速に発見し、対策を講じる必要があります。

対策の1つは、ビューをカテゴリー化することです。これがパフォーマンスに貢献する理由は、カテゴリーは常に表示され、1行分のデータを保持するからです。このため、サンプルの[収益別]ビューでは、ユーザーは数十ものカテゴリー (たとえば、[収益]や[担当者]) を素早く見ることができます。三角アイコンをクリックしてカテゴリーを開くと、サーバーとの間で素早くやり取りが行われ、カテゴリー内の文書をこのユーザーに表示できないことが判断されます。しかし、これにかかる時間は、400,000文書を一度に調べることに比べ、非常に短いことが明らかです。

一方、ほとんどすべての三角アイコンをクリックして展開しても、文書がまったく表示されなければ、ユーザーは不満に思うはずです。この例では他の対策も考えられますが、収益別にすべての文書を表示するビューは、データベースの0.01%にしかアクセスできないユーザーがアクセスするようなビューではないでしょう。ユーザーが持っているアクセス権と矛盾しています。しかし、ユーザーが持っている権限以上のデータを含むビューに多くの人々がアクセスすることが、ビジネス的に意味のあるケースも数多くあります。このセクションの最後で、読み込みアクセスが制御された文書を含むデータベースで速いビューを構築するためのヒントを示します。

[読者]フィールドとビューについて、要点を2つまとめておきます。まず、通常の実稼働環境では、図3に示したような明確なデータを得られることはほとんどありません。[読者]フィールドによって生じるパフォーマンスの問題は、エージェント、ビューの索引作成など、他の多くのパフォーマンスの遅延として現れることが多いようです。これらの問題は、他の問題を引き起こす可能性があります。たとえば、どのユーザーに対してもビューが遅いときは、問題はビューの索引作成と考えられます。この場合、根本的な問題は[読者]フィールドにあり、ユーザーがビューを開くときに、サーバーでは長時間の計算が強いられています。

次に、私たちのテスト (図3) は、最もよい状態でのシナリオを表しています。その理由は、一度に一人のユーザーだけが操作しているからです。テストでは、データの量やスケジュール済みエージェントを用いた索引作成の問題を再現できるとしても、数百人のユーザーが、読み込みアクセスが制御された文書を含むビューに一斉にアクセスしたときに生じるパフォーマンスの急激な悪化を表すことは不可能です。アプリケーションで[読者]フィールドを使用するときは、危機的な状況を避けるために、ビューのパフォーマンスに十分な注意を払うことが必要です。

読み込みアクセスが制御された文書でのパフォーマンスの強化

読み込みアクセスが制御された文書が含まれる場合に、アプリケーションまたはビューのパフォーマンスを良好に保つためのヒントを以下に示します。

• [単一カテゴリの表示]を使用した埋め込みビュー：明らかに、これが最もよい方法です。すべての文書を1つのカテゴリーで見られるようにデータが構成されている場合は、そのカテゴリーのコンテンツだけを非常に素早くユーザーに表示できます。ユーザーがカテゴリーを切り替えられることに意味があるケースもありますが、このような場合は、ユーザーが他のカテゴリーのコンテンツを表示できるかどうかを考慮する必要があります。しかし、ほとんどの場合、ビューは[個人売上]のようなもので、現在のユーザーに関するすべての売上文書が表示されるようになっています。この種類のビューの短所は、Lotus Notes Clientのユーザー・インターフェースが、ネイティブのビュー表示ほど優れていない点です。Webブラウザーの場合は表示も問題なく、Webブラウザー・アプリケーションでこの種類のビューを使用しない理由がありません。実際に、パフォーマンスもたいへん優れていて、読み込みアクセスが制御された文書を含むビューをこの方法で開く方が、読み込みアクセスが制御された文書を含まないネイティブ・ビューを開くよりも速いぐらいです。
• ローカル・レプリカ：多くの会社では、売上トラッキング・データベースでローカル・レプリカを使用し、接続していない状態でも営業担当者がデータベースを使用できるようにしています。これは多くの用途で優れたソリューションになりますが、[読者]フィールドの値が変更されたときに、読み込みアクセスが制御された文書の扱いが面倒になります。あるローカル・レプリカでは文書を非表示にし、別のローカル・レプリカでは表示することが必要です。
• [共有 (最初は個人)] ビュー：これはLotus Notes Client用の優れたソリューションですが、いくつかの短所もあります。まず、ブラウザーでは使用できません。次に、ビューはローカルまたはサーバーに保存する必要があります。ローカルに保存する場合は、お客様によっては問題となることがあり、サーバーに保存する場合は、パフォーマンスとメンテナンスに関する固有の問題があります。3番目の短所として、アプリケーションの設計を変更するときに、これらの (現在は) 個人ビューの設計を更新することは面倒です。最後に、このような個人ビューを大量に作成し、使用したことが原因とみられるパフォーマンスの問題を一部のお客様から指摘されています。
• カテゴリー化されたビュー：図3で示したように、カテゴリー化されたビューは、[読者]フィールドに関して、非常に速く開ける可能性があります。カテゴリー化されたビューを用いると、サイズが大きくなって索引作成が遅くなりますが、通常、[読者]フィールドによるパフォーマンスの問題を排除できます。ここで注意したいのは、ユーザーがこのようなビューをフレンドリーに感じないこともあることです。アプリケーションではこのような印象は避けたいものです。

最後のヒントとして、使用すべきではない機能について説明します。[空のカテゴリを表示しない]機能は、理論的には、上記のヒントと共に使用して、ユーザーが見られる文書を含むカテゴリーだけを表示するビューを作成できます。しかし、実際には、階層なしのビューでのパフォーマンスの特徴と似たような結果となるため、パフォーマンスが重要なケースではこの機能を使用しないほうがよいでしょう。

上に戻る

ビューのパフォーマンスに関する一般的なヒント

読み込みアクセスが制御された文書の有無にかかわらず、ビューのパフォーマンスに関するヒントを紹介します。

時刻/日付の式

@Nowまたは@Todayを列や選択式で使用すると、ビューが更新されるたびに、ビューが再構築されます。このため、このような式を使用する場合は、ビューの更新を[手動]または[自動 (周期)]で行うことを考慮してください。この方法を用いると、ユーザーがビューを開いたときに、ビューが再構築されるまで待つ必要がありません ([自動 (周期)]の場合は、ほとんど待つことがありません)。短所としては、ビューの更新を試みずに開くので、古いビューが表示されることがあります。ビューの内容とその変更頻度を考慮して、これらの索引オプションを安全に使用できるかどうかを判断してください。

クリック・ソートは慎重に使用する

クリックによるソート (クリック・ソート) は、アプリケーションのほとんどの公開ビューで使用できる優れた機能です。しかし、非表示の検索ビューで、クリック・ソートが列に設定されていないことを確認することも重要です。これがあると、ユーザーに機能を提供しないにもかかわらず、ディスク・スペースと索引作成時間要件が増加するからです。また、この機能を使用するときは、機能性を損なわずにディスク・スペースと索引作成時間を削減するために、昇順または降順を使用し、両方を使用しないことを検討してください。矢印が1つの場合は、オンとオフの切り替えとして使用できるので、3つの切り替えよりも使いやすいと考えられます。

索引にユニークなキーを作成する

あまり知られていませんが、パフォーマンスを強化する機能の1つに[索引にユニークなキーを使用する]オプションがあります。このオプションを検索ビューで使用すると、検索時間を飛躍的に改善できます。この機能を選択すると、ビューは重複するすべてのエントリーを廃棄します。たとえば、会社名だけを表示する400,000の文書があり、この中で固有の会社名が1,000あるものとします。この機能を使用すると、各会社の最初の文書だけがビューの索引に保持されます。この機能自体にも若干のオーバーヘッドがありますが、ビューのサイズが飛躍的に減少する事実と比べると、はるかに小さいものです。ただし、複数値フィールドの結果を表示する場合、データの損失を防ぐために、コードを工夫しなければならい点に注意してください。

たとえば、100,000文書を持つデータベースで、すべての文書に[業種]という複数値フィールドが含まれるケースを考えます。ユーザーが新規文書を作成したときに、[業種]ドロップダウン・リストに値が表示されるようにするために、選択済みの固有の業種リストを検索します。このとき、業種が1つの列に表示されるビューでこのユニーク・キー機能を使用すると、[自動車]や[航空機]といった値を含む新規文書が表示されない可能性があります。この場合、[自動車]を含む他の文書がすでにビューに表示されているからです。このため、[航空機]という新しい値は、検索式によって選択されなくなります。

この問題を避けるには、列式で「@Implode(Industry; "〜")」などの式を使用し、ドロップダウン・フィールドの検索式で「@Explode(@DbColumn("Notes"; ""; "(LookupViewName)"; 1); "〜")」を使用します。ビュー内で多少の重複が生じますが、データの損失はありません。

カラー・プロフィール

カラー・プロフィールを使用すると (たとえば、メール・テンプレート)、カラー・プロフィール文書の変更によって、そのカラー・プロフィールを使用しているすべてのビューでビューの再構築が必要になります。

デフォルト・ビュー

ユーザーがアプリケーションを開くたびに、デフォルト・ビューが表示されます。このビューが素早く開くビューであることに、常に注意してください。これに関する興味深い例が、メール・ファイルです。多くのユーザーにとって、デフォルトで開くビューは[受信ボックス](フォルダー) です。ユーザーが受信ボックスを整理する習慣を持たず、数千もの文書が受信ボックスにあるケースと、ユーザーが定期的に受信ボックスを整理し、ビュー/フォルダーに数百程度の文書があるケースを比較すると、文書が多い場合はメール・ファイルを開くときの速度が遅くなります。ちなみに、受信ボックス内の古い文書を定期的に削除するポリシーを設定している会社があるのは、このためです。ポリシーにより、ユーザーがこれらの文書を別のフォルダーに移動するため、ユーザーとサーバーのパフォーマンスが改善されます。

上に戻る

まとめ

この連続記事の結論として理解していただきたいのは、アプリケーションのパフォーマンスは制御できる、という点です。一般的な認識 (および、この記事に含まれる情報やヒント) を慎重に適用することで、ユーザーが望む以上のアプリケーションのパフォーマンスを維持できるでしょう。

参考文献

学ぶために

• developerWorks Japan: Lotus: Lotusの日本の技術情報サイトです
  
  
• developerWorks: Lotus(US) : Lotusの英語の技術情報サイトです
  
  
• この連載記事の第1回目『Lotus Notes/Domino 7 アプリケーションのパフォーマンス:第1部:データベース・プロパティーと文書コレクション』もお読みください。
  
  
• Lotus Notes/Dominoにおけるアプリケーションのパフォーマンスに関するトラブルシューティング情報については、developerWorksのLotusに関する2つの記事『アプリケーション・パフォーマンスのトラブルシューティング: パート 1: トラブルシューティングの手法とコードのヒント』と『アプリケーション・パフォーマンスのトラブルシューティング: パート 2: Lotus Notes/Domino 7 の新規ツール』を参照してください。
  
  
• 加えて2つの記事『アプリケーションのパフォーマンス・チューニング 第1回』と『アプリケーションのパフォーマンス・チューニング 第2回』は、Lotus Notes/Domino 5および6でアプリケーションのパフォーマンス・チューニングについて有用な情報をご提供しています。
  
  
• 『Lotus NotesとDomino Designer 7.0の新機能』は、Lotus Domino Designer 7.0の新しい機能を紹介しています。
  
  

議論するために

• ディスカッション・フォーラム(US)にご参加ください。
  
  
• developerWorksブログ(US)を通じて、developerWorksコミュニティーに参加できます。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• ビューの索引作成(Updateタスク)を理解する
• [読者]フィールド
• ビューのパフォーマンスに関する一般的なヒント
• まとめ
• 参考文献
• 著者について
• コメント