|
 |
ソフトウェア > Lotus > Lotus Developer Domain > 製品別技術情報 > Lotus Notes/Domino >
LDD Today
アプリケーションのパフォーマンス・チューニング 第1回
|
|
 |
by Tara Hall and Raphael Savir
レベル：中級者
対象: Notes/Domino
原文の掲載：2003年4月1日
アプリケーションのパフォーマンスは、ある環境下や特定の負荷がある場合のアプリケーションの動作効率を測る基準となります。アプリケーションのパフォーマンスを測定する方法をご存知ですか。必要なのは、お使いの実稼働環境と同様のネットワークを持つ隔離されたテスト環境、ユーザーとユーザーのタスクをシミュレーションする負荷テスト・ソフトウェア、そして十分な時間だけです。CPU、RAM、NICなどの変数をたやすく排除できるサーバー・パフォーマンス・テストと違い、アプリケーションのパフォーマンス・テストでは、1つのビュー内の1つのフォームの1つのフィールドを非常に細かく、しかも同時にテストする必要があります。Notesカスタム・アプリケーションの中には複雑なものもあるので、このようなテストは単調で退屈なだけでなく、果てしなく続くように思われます。アプリケーションの最適な動作を妨げている可能性がある設計要素、計算式、スクリプト、またはプロパティを絞り込むのにどれだけ時間がかかるのかは、やってみないと分かりません。
しかし、この記事で説明するように、簡単な方法もあります。Notesカスタム・アプリケーションを評価して、パフォーマンス関連の問題を診断してきた数年の経験をもとに、著者はアプリケーションのパフォーマンスに影響を与える可能性が高いプロパティをまとめました。このシリーズ記事の最初のトピックとして、アプリケーションのパフォーマンスに影響を与えることが分かっているデータベース・プロパティ、ビュー・プロパティ、およびフォーム・プロパティを取り上げます。最高のパフォーマンスを得るために、あるプロパティを使うべき場合と使うべきでない場合を紹介し、可能な場合には、代替ソリューションを提供します。この記事では、読者が経験を積んだNotesアプリケーションの開発者であるということを前提にしています。
アプリケーションが実稼働に入ると、データベース・プロパティは見落とされがちになります。しかし実際は、あるデータベース・プロパティを使用可能または使用不可にすることで、機能や開発時間、管理用リソースを1つも損なうことなく、パフォーマンスの向上を図ることができます。パフォーマンスに影響を与える次のような一般的なデータベース・プロパティについて考えてみることにします。
- 未読マークを使用しない
- 空きスペースに上書きしない
- LastAccessedプロパティを保持
- 文書の階層情報を使用しない
- Webアクセス：SSL接続の要求
これらのプロパティはすべて、［データベース・プロパティ］ダイアログボックスの中にあります。最初の4つのプロパティは［Advanced］タブに、また最後のプロパティは［Database
Basics］タブにあります。
未読マークを使用しない
正直なところ、このプロパティは二重否定のように読めて分かりにくいのですが、デフォルトでは、すべての既読文書と未読文書がデータベース内で追跡調査されます。ディスカッション・フォーラムでは、新規で未読のトピックや応答を把握するニーズがあるので、この機能は便利です。しかし、既読および未読文書の追跡調査はアプリケーションのパフォーマンスに影響を及ぼします。たとえば、1,000,000の文書を格納しているナレッジ・データベースがあるとします。10,000人のユーザーがこのデータベースにアクセスし、そのうち多くの人が複製選択式を使ってデータベースをローカルで複製します。複製時に、ローカルとサーバー上の複製コピーが未読マーク・テーブルに同期する間、ユーザーは最初の遅延を実感します。このプロセスには実際のデータ複製と同じだけの時間が必要です。つまり、ユーザーは複製時に長い間待たされることになります。また、サーバー上のデータベースにアクセスするユーザーがデータベースを最初に開いたときにも、ユーザーは遅延を感じます。これは、プログラムが未読マーク・テーブルをくまなく読んで、そのユーザーに対して既読として表示する文書と未読として表示する文書を判断する必要があるからです。この遅延はわずか2、3秒かもしれませんが、ユーザーの目には、アプリケーションのマイナス・ポイントとして映るおそれもあります。
このオプションを使用不可にするには、［データベース・プロパティ］ボックス内の［Advanced］タブの［未読マークを使用しない］オプションを選択します。Release
5およびNotes/Domino 6では、このオプションは、特定のビューだけでなくデータベース全体に適用されます。
空きスペースに上書きしない
Notes Release 3以前のリリースでは、Notesは削除されたデータを暗号化しないまま、空きスペース（空白）がデータベース圧縮時に削除されるまで持ち続けていました。Release
4では、削除されたデータが検索できないようにランダムな文字で上書きされるように多少変更されました（これは、「空きスペースの上書き」と呼ばれます）。Release
5およびNotes/Domino 6では、この機能を使用可能にするか使用不可にするかを選択できます。空きスペースの上書きは、データベースのパフォーマンスに悪影響を及ぼします。
この特徴を理解するために、たとえば、デスクトップ・パソコンから削除された文書について考えてみましょう。Windowsオペレーティング・システム上の文書を削除すると、その文書はすぐごみ箱に入れられます。それからごみ箱を空にすると、文書は完全に消えたように思われます。ところが、ごみ箱を空にした後で、その文書がやはり必要だったことに気づいたとします。この文書は完全に失われたのでしょうか。必ずしもそうとは言えません。ごみ箱の中にはもうありませんが、コンピューターの中にはまだ存在しているのです。適切なソフトウェア（たとえばNorton
Utilities）の助けを借りると、この削除された文書を検索することができます。
Notes/Dominoでは、そこでセキュリティー対策として、Notes文書が削除されると、Notesは削除されたデータを上書きして、誰にも検索できないようにします。F9を押すか［ビュー］-［更新］を選択すると、文書は削除されます。つまりNotes文書の以下の文書を削除した場合、
| The quick brown fox jumped over the lazy dog |
|
から
| XX XXXXXXXXXXXXX XXXXXXXXXXX XX X XXXXXXXXXX |
|
になると考えてください。
注：この例は、Notesが削除されたデータを上書きする様子を正確に表現したものではありません。
この時点では、データ自体が破壊されているため、誰かが文書を検索できるかどうかは問題ではなくなります。なお、文書のソフト削除(一時的削除)では、Notesはデータを上書きしません。完全削除の場合だけ上書きが行われます。
ほとんどの場合、上書きされたデータを取っておく必要はありません。ただし、次のように削除されたデータの上書きをNotesに続行させたほうがよい場合があります。
- 使用しているサーバーおよびデータベースへの物理的アクセスが、無許可ユーザーにより可能であり、データへのアクセスの危険がある場合。
- データベースが暗号化されていない、またはACLの設定がデータベースを攻撃されやすい状態になっている場合。
- 組織のセキュリティー・ポリシーがこの機能を要求している場合。
組織、サーバー、データベースがこれらに該当しない場合は、［空きスペースに上書きし
ない］オプションを選択してこのプロパティを使用不可にすることを検討してください。
LastAccessedプロパティを保持
［LastAccessedプロパティを保持］は、Release 4で導入されました。この機能は文書が最後にアクセスされた日付（つまり、最後に文書が参照もしくは変更された時点）をトラッキングします。デフォルトでは、データベースは文書が最後に変更された時点のみを追跡調査しますが、［LastAccessedプロパティを保持］オプションを選択すると、データベースは文書が最後に参照された時点も追跡調査できます。当然のことながら、最高のアプリケーションのパフォーマンスを得るには、このオプションを選択解除しておく必要があります。
ただし、文書をアーカイブしている場合にはこのオプションが役に立ちます。たとえば、1,000,000の文書を格納しているナレッジ・データベースの例に戻って、毎日1,000の新規文書がデータベースに追加されると想像してみましょう。そのように非常に多くの文書が追加されるので、古い文書をアーカイブする必要があります。このような場合に［LastAccessedプロパティを保持］オプションを使って、文書が最後にアクセスされた時点を調べ、アーカイブすべき文書を決めることができます。たとえば、LastAccessedプロパティをもとに、アーカイブ機能をセットアップして、1年半以上開かれたり参照されたりしていない文書をアーカイブすることができます。
このオプションは、文書が期限切れとなったり、陳腐化したり、ライフ・サイクルが短かったりする文書をアーカイブするときの補助機能として使うとよいでしょう。そのようなデータベースとしては、たとえばディスカッション・データベースやワークフロー・データベースなどが考えられます。一方、文書があまりアクセスされず、トラッキングする最終アクセスの日付の必要性がないようなデータベースでは、このオプションを使わないでください。たとえば、ヘルプ・デスク・アプリケーションのデータベースなどが考えられます。
もう1つ覚えておかなければならないのは、LastAccessedプロパティはWebアプリケーションには適用できないということです。このプロパティでは、Webブラウザーでの参照は無視されます。
文書の階層情報を使用しない
［文書の階層情報を使用しない］オプションは、アプリケーションで文書の階層情報を求める@式（@AllChildrenおよび@AllDescendents）を利用できるようにします。これらの機能を使えば、特定の基準をもとに親文書とその応答文書すべてを表示するビューを作成することができます。たとえば、10,000のメイン・トピックと100,000の返答文書を格納しているディスカッション・データベースを例に考えてみましょう。「アプリケーションのパフォーマンス」といったカテゴリーだけを表示するビューをいくつか作ったとします。100のメイン・トピックだけがこのカテゴリーに分類される場合、ビューは100のメイン・トピックに加えて、それらに対する応答すべて（応答文書への応答なども含む）を表示すると開発者は期待します。従来、Notesは次のようなselection式を使っていました。
| SELECT (Form = "Main Topic" & Categories = "Application
Development") | @IsResponseDoc |
|
残念なことに、この式では100,000の応答文書すべてが返されます。ビューが文書の階層構造を持っているので、ほとんどの文書は多分非表示になっているでしょう。しかし、すべての文書が呼び出されて、ビューの索引付け処理を遅らせ、ディスク・スペースを占有してしまうのです。文書の階層情報（Release
4で使用可能になり、Release 5およびNotes/Domino 6ではオプション）を利用すると、次のように少し違った式を使えます。
| SELECT (Form = "Main Topic" & Categories = "Application
Development") | @AllDescendants |
|
この式では検索対象の文書セットだけが返されるため、ビューの索引付けやディスク・スペースの必要量は最小限に抑えられます。
ここまでは、この機能を使用可能にする（つまり、このオプションのチェックマークを外しておく）理由だけを説明してきました。しかし、アプリケーションで@AllChildrenまたは@AllDescendantsを使った式を使用しない場合は、アプリケーションプログラムがこの情報を保持しておく理由はないため、［文書の階層情報を使用しない］オプションを選択して文書の階層情報を使用不可にすることで、処理サイクルを節約できます。
Webアクセス：SSL接続の要求
［Webアクセス］の［SSL接続の要求］オプションを用いると、各WebトランザクションがSSL（Secure
Socket Layer）接続を通して行われ、クライアントとサーバー間で伝送されるすべてのデータが暗号化されます。SSLを使用可能にすると、パフォーマンスが約10%低下します。ただし、この割合は各アプリケーションのアーキテクチャーに影響されます。
SSLを使用可能にすると、各情報パケットが暗号化されるので、クライアントとサーバー間で多数の伝送を必要とするアプリケーションでは、多くの暗号化処理が必要になります。
たとえば、SSLを使ってすべてのフォーム・データを暗号化するフォームがあるとします。フォームには、@DbLookup式が含まれています。SSLはクライアントとサーバー間のトランザクションすべてを暗号化するので、フォーム・データだけでなく、ルックアップ・トランザクションも暗号化されます。
アプリケーションによってはSSLを使用不可にできない場合もあります。たとえば、特定のアプリケーションでSSLを実行することが組織のポリシーで定められている場合があります。また、サーバーとクライアントが別の国に置かれている場合などは、SSLを使用可能にするのが当然です。ネットワークを信頼してよいかどうかがはっきりしない場合は、SSLを使用可能にする意味があります。しかし、信頼できるネットワーク（危険にさらされることはないと考えられるネットワーク）では、アプリケーションにとってSSLは必要ないため、このオプションを使用不可にして、パフォーマンスの低下を防いでください。
プライベート・ビュー/フォルダーの作成
プライベート・ビュー/フォルダーの作成はACLオプションです。この特権を持つユーザーは、プライベート・ビューやプライベート・フォルダーを作成し、それらをデータベースのホスト・サーバーに保存できます。ビュー、特に大きいビューをたくさん作成すると、余計な索引付けが必要になるため、パフォーマンス上の問題となるおそれがあります。サーバーに保存されたプライベート・ビューおよびプライベート・フォルダーを管理者や開発者が削除するのは困難である、という点にも注意してください。
圧縮およびUpdallタスク
アプリケーションを圧縮して、ビュー索引を更新するためにUpdallタスクを実行するのは、データベースの運用としては望ましいのですが、アプリケーションのパフォーマンス改善には一般的につながりません。空白の割合が非常に多いデータベースなどの例外はありますが、空白が5%や10%のデータベースを圧縮しても、顕著なパフォーマンスの向上は見られません。
ビューのパフォーマンスに影響を与える主な分野がいくつかあります。
- 時間/日付依存型の計算式（選択式または列での式）
- オンザフライでの列ソート
- 読者名フィールド
- ODBCアクセス
時間/日付依存型ビュー
時間/日付依存型ビューは、@Modifiedや@Nowなどの時間/日付計算式、または時間/日付計算式を含む選択式を持つ列を表示するビューです。この種のビューは優れた機能を提供しますが、パフォーマンスを犠牲にする傾向があります。Dominoサーバーは15分毎にUpdateタスクを実行し、データベース内のビュー索引すべてを更新します。このタスクの設定を変更することはできません。（つまり、タスクを別のスケジュールで実行するようには設定できません）。たとえば、午前9時にタスクが実行され、データベース内のビューすべてが更新されるとします。その後9時2分に、データベース内のある文書が変更されたと仮定します。9時15分になると、Updateタスクが再実行され、システムはこのデータベース内の文書が変更されたことに気づきます。新規メールが到着したり、複製、作成、更新、削除などの操作が文書に対して実行される可能性がありますが、いずれにせよ文書が最後のUpdateタスク実行時から変更されているので、このデータベースは期限切れビューについてチェックする必要が生じます。
この時点では、変更された文書を含む可能性のあるビューすべてに期限切れフラグが設定されます。また、時間/日付依存型ビューすべてにも期限切れフラグが設定されます。したがって、合理的に考えてアップデートする必要があるビューのアップデートに加えて、インデクサーは時間/日付依存型ビューもすべてアップデートしなければなりません。ところがさらに悪いことに、これらのビューは予め更新できないので表示要求のタイミングで再作成する必要があり、再作成にははるかに長い時間がかかります。どのくらいの時間がかかるのかというと、何らかの依存診断プログラムを実行した場合、一般的なビューの更新はおそらく100ミリ秒で済みますが、一般的な時間/日付依存型ビューの更新は実際には再作成になるので、10〜50秒（ミリ秒ではありません）かかります。チェックするデータベースと15分毎にアップデートするビューが多数あるビジーなサーバーでは、1つのビューにこのような時間を費やす余裕はありません。
なお、［ビュー・プロパティ］ボックス内の［更新］フィールドを（［自動］や［自動（周期）］ではなく）［手動］に設定すると、15分毎のUpdateタスクに影響することなく、ユーザーはビューを素早く開くことができます。
ビューの更新が［手動］に設定されていない場合は、ユーザーがビューを開くたびに、再作成が行われます。言うまでもありませんが、［手動］に設定した場合は、ユーザーがビューを開いたときにビューが最新の状態であるとはかぎりません。そのため、データが最新でない可能性があるデメリットよりパフォーマンスのメリットに重点をおく場合には、この設定を使ってください。
時間/日付依存型ビューは非常に便利な（しかし非常に犠牲の多い）オプションなので、注意して使うようにしてください。
ログ・ファイルのチェック
ビューの更新や再作成にかかる時間がはっきりしない場合は、ログ・ファイルを使います。「Log_update=2」をサーバー設定文書に設定し、インデクサーがビューを更新または再作成した時間を記録します。更新または再作成された各データベースの各ビューがリストされるため、特定のビューまたはデータベースに費やされた時間を追跡調査することができます。少し実践するだけで、サーバーのどのような問題でも素早く突きとめることができます。
時間/日付の選択肢
時間/日付依存型ビュー向けに実行できるソリューションの選択肢がいくつかあります。
- 『Time/Date Views in Notes: What Are the Options?』に記載されている選択式の@Textを使います。この選択肢には制限がありますが、非常に便利でかなりの効果が期待できます。
- エージェントを実行し、古い時間/日付依存型ビューで表示されるはずの文書をマークします。たとえば「Status
= "Open"」で「DueDate」がその日より古い文書を表示するビューがある場合、エージェントを夜間に実行し、該当文書に「OverDueFlag
= "Yes"」というマークを付けることができます。そうすれば、ビューの選択式はそのフラグだけをチェックすれば良いわけです。文書が閉じられると、このフラグは消される可能性があります。これはシングル・サーバーで運用しているデータベースには極めて適切なソリューションとなりますが、ユーザーが主にローカルの複製を使っている場合には、エージェントのデータの変更を毎日複製しなければならないので、適切なソリューションとは言えません。同様に、データベースが世界中の何十台ものサーバーに複製される場合は、このソリューションを使わないほうがよいでしょう。
- 文書を日付別に分類するビューを作成します。このソリューションはあまりにシンプルなので、見落とされがちです。上の例を使って、「Status
= "Open"」文書すべてを「DueDate」で分類して表示するビューを作ります。ユーザーは参照したい日付カテゴリーにスクロールするだけで、期限が過ぎた文書、または期限が迫っている文書を簡単に調べることができます。
列のソート
列のソートは、ユーザーがビューの列を昇順、降順またはその両方でソートできるオプションです。ビュー内の列のソート矢印が増える度に、ビュー索引とビューの更新にかかる時間が増加します。ユーザー・インターフェースやメンテナンスの観点からは、複数のビューを使うよりもいくつかのソート矢印を持つ1つのビューを使うほうが好ましいと言えますが、パフォーマンスの観点からは、ビュー全体の数を減らさないままでビューに多数のソート矢印を追加しないようにすることが大切です。具体的には、ビューにソート矢印2個を追加すると索引サイズと時間は約3倍になります。ソート矢印を4個追加するとビュー索引サイズと時間は約5倍に増えるという具合です。
ヒント：ルックアップだけに使われる非表示のビューをチェックします。これらのビューではソート矢印は使われないため、ソート矢印がある場合には削除する必要があります。
読者フィールド
読者フィールドはビュー・プロパティではありませんが、ビューのパフォーマンスに影響を与える可能性があります。読者フィールドは文書のセキュリティーを提供しますが、読者フィールドを持つ文書を表示するビューには悪影響を及ぼす可能性があります。たとえば、10,000人の従業員向けの人事データベース、および10,000の文書すべてを表示するフラット・ビュー（分類されていないビュー）があるとします。読者の制限があるので、従業員は自分の文書しか見ることができません。ある従業員がデータベースを開くと、Dominoサーバーは文書を調べ、そのユーザーに示すべき文書を決めます。読者がない場合は、通常最初の文書が30行程度ユーザー向けに表示され、画面がいっぱいになります。任意のデータベースでビューを開いて下向き矢印を押すと、簡単にこの動作を確かめられます。素早く10行程度スクロールすると、普通1秒以内のポーズがあります。この間サーバーは、次に表示するデータ一式を取り込みます。30行程度のスクロールが再開し、またポーズがあるという具合に進みます。
しかし、例となっている人事アプリケーションでは、サーバーはユーザーの画面をデータで満たすことができません。これ自体は問題ではありませんが、サーバーは画面を満たすことができないことを全く認識できないので、ユーザーに表示できる文書を見つけるために、10,000の文書すべてを調べ続けます。全文書を調べ尽くしてから、やっとサーバーはあきらめ、文書を1つだけ表示することになるのですが、遅延はかなりの長さになる場合があります。隔離された環境では遅延は数秒かもしれませんが、多数のユーザーが似たようなタスクを実行しようとしている実世界の実稼働環境では、そうした遅延のために大多数のユーザーがタイムアウトになりかねません。
この問題を避けるのに有効な選択肢がいくつかあります。
- ビューを分類し、［データベースを最初に開くときすべてを省略する］オプションを選択して、ビュー内のカテゴリーをまず折り畳んで表示します。この設定がパフォーマンスを若干悪化させるのも事実ですが、この状況では大きな効果があります。
- 文書が存在するカテゴリーだけを表示する［空のカテゴリを表示しない］オプションを選択しないようにします。このオプションを選択すると、フラット・ビューを使った場合と同じ結果になり、サーバーは、ユーザーにデータを表示する前に10,000の文書すべてをチェックする必要があります。
- 1つのカテゴリーを表示する埋め込みビューを使います。@UserName式を使って、そのユーザーの文書だけを表示します。このソリューションは大変良く機能し、Webブラウザーに対してもすばらしい効果を発揮します。
ユーザーがWebブラウザーを使っていようと、Notesクライアントを使っていようと、ビューの読者名フィールドに関連するパフォーマンスの問題は同じである点に注意してください。
ODBCアクセス
［ODBCアクセス］プロパティの［索引にユニークなキーを作成する］は、ユニークなキーをデータベースの対話性に提供します。このプロパティは、ルックアップを高速化するために使用することができます。方法は次のとおりです。10,000のメイン・トピックと100,000の返答文書を格納したディスカッション・データベースがあるとします。このデータベースには非表示のビューがあり、このビューは既存の全カテゴリーを調べるために10,000のメイン・トピックだけをリストしています。［ODBCアクセス］プロパティをこの非表示のビューで選択すると、各カテゴリーに対して文書の数を1つに削減できます。このプロパティは重複文書をすべて削除します。非表示のビューで@DbLookupを使うと、ビュー・サイズが劇的に小さくなるので、ルックアップが高速化されます。たとえば、データベース内にユニークなカテゴリーが50しかない場合は、この非表示のルックアップ・ビューには、10,000ではなく50の文書だけが含まれることになります。
文書で複数のカテゴリーが選択されている場合は、ビューの列式にコードを追加して、全カテゴリーが確実に表示され、ルックアップできるようにします。
アプリケーションのパフォーマンスに影響を与えるフォーム・プロパティは、実際に［フィールドを自動更新］の1つだけです。フォームで自動更新機能を使用可能にすると、フィールドを移動する度に、自動更新機能がフォームの前のフィールドすべてをアップデートします。
たとえば、フォームの2番目のフィールドに移動すると、自動更新機能はフォームの1番目のフィールドをアップデートします。3番目のフィールドに移動すると、1番目と2番目のフィールドがアップデートされるという具合ですので、この機能は結局アプリケーションのパフォーマンスを低下させることになります。特にフォームでワークフローとルックアップが使われている場合には、この傾向が強くなります。validation式を含む単純なフォームでは、自動更新機能のパフォーマンスへの影響ははるかに小さくなります。複雑なフォームを使うときは、自動更新機能ではなくexitイベントを使うことを検討してください。
この記事では、アプリケーションのパフォーマンスに影響を与える最も一般的ないくつかのプロパティについて検討しました。しかし、カスタム・アプリケーションには、パフォーマンスに影響を与えうる固有の要因が組み合わさって存在します。この記事で説明されているプロパティを使用可能または使用不可にすることでパフォーマンスを改善できるかもしれませんが、さらなる改善点を見出すためにはアプリケーションのテストが役に立つ場合もあるでしょう。ただし、アプリケーションのパフォーマンス・テストは難しく、時間がかかることだけは忘れないでください。このシリーズの次の記事では、アプリケーションのパフォーマンスに影響を及ぼすエージェントおよびコードについて考えてみます。
|
|
|
|
|
