キャッシュのサイズ設定はおそらく、eDirectoryの全体的なパフォーマンスに影響を及ぼす最も重要な要素です。キャッシュ可能なアイテム(ブロックおよびエントリ)の数が増すにつれ、全体のパフォーマンスも向上します。キャッシュの中でブロックやエントリが見つかる回数の割合を、ヒット率と呼びます。比率が高くなると、パフォーマンスが良くなります。iMonitorを使用することで、ヒット率を確かめることができます。
ブロックキャッシュは更新操作にとって最も効果的です。エントリキャッシュは、エントリのベーススコープ検索を行う操作にとって最も効果的です。とはいえ、1レベルおよびサブツリースコープ検索のどちらも、ブロックキャッシュだけでなくエントリキャッシュも使用します。ブロックキャッシュは、インデックスを取得する際に使用されます。必要に応じて適切な型のインデックスを作成してください。詳細は「インデックスの選択」を参照してください。
ブロックキャッシュに失敗すると、ディスク読み込み操作が行われます。ディスク読み込みは常に高くつきますが、ファイルシステムキャッシュからブロックを取得できる場合は避けることができます。
データベース全体をブロックキャッシュにキャッシュするために必要なメモリの量は、ディスク上のデータベースのサイズとほぼ同じで、データベース全体をエントリキャッシュにキャッシュするために必要なメモリの量は、ディスク上のデータベースのサイズのほぼ2倍から4倍です。システム上のメモリが少ない場合は、エントリキャッシュを減らし、ブロックまたはファイルシステムキャッシュを増やしてください。
読み込みがディレクトリ内のエントリ集合に集中している場合、エントリキャッシュのヒット率が向上する限り、エントリキャッシュを増やしてください。
読み込みパターンが完全にランダムで、DIBが利用可能なRAMよりもはるかに大きい場合、エントリキャッシュよりもブロックキャッシュおよびファイルシステムキャッシュが大きくなるようにしてください。
どんな方法でeDirectoryをチューニングし、パフォーマンスを改善するとしても、実験的なテストをする必要があります。検索が集中する環境でのエントリキャッシュとブロックキャッシュの適切な比率は、2:1です。他のプロセスのために十分なメモリが残っていることを確認してください。FLAIMキャッシュサイズを減少させることができるとしても、ページスワッピングは避けてください。
FLAIMはあらかじめ割り当てられたキャッシングを提供するので、eDirectoryキャッシュに割り当てられるメモリがネイティブのオペレーティングシステムメモリマネージャに断片化させられることは絶対にありません。
インデックスは、1レベル検索またはサブツリースコープ検索のパフォーマンスを向上させるためのものです。動的グループも、1レベルまたはサブツリースコープ検索を使用します。インデックスは、ベーススコープ検索では使用されません。
Presenceインデックスはpresent値およびnot present (deleted)値の間で違いがないので、主に内部的な目的のために使用されます。アプリケーションがPresence型の検索クエリを実行する場合、このインデックスは決して使用されないので、アプリケーションは自身のために作成されたPresenceインデックスを持つべきではありません。
アプリケーションは属性に対してValueインデックスを作成することができ、これはほとんどの検索に対して十分です。FLAIMは、属性に対してPresense検索およびSubstring検索の両方を行うために、Valueインデックスを使用できます。
Substringインデックスは、属性に対する更新の速度を著しく落とします。Substringインデックスをサポートするために必要なインデックスブロックの数は、Valueインデックスと比較してかなり大きくなります。それらをキャッシュするためにより多くのブロックキャッシュが必要になるということです。必要なときにだけ、Substringインデックスを作成してください。ほとんどの検索にとって、Valueインデックスは十分なはずです。とはいえ、ValueインデックスによるSubstring検索では許容できるパフォーマンスが得られない場合、属性に対してSubstringインデックスを作成することができます。
選択したインデックスにかかわらず検索操作が完了するのに長い時間がかかる場合、検索フィルタの属性の一つに対して、新しい値インデックスを導入することもできます。インデックス付けしたときに最高の結果を生み出す属性を選んでください。
ブロックキャッシュは、更新操作にとって最も効果的です。インデックスもブロックキャッシュにあります。インデックスは検索を高速化するのに役立ちますが、インデックスが多すぎるとサーバがそれらを維持するのに忙しくなります。属性値が変更、追加または削除されると、インデックスは変更されます。大規模なアップロード操作中は、アップロード高速化のためインデックスを無効にできます。
RFLディレクトリをDIBディレクトリとは異なるディスクに置くことで、パフォーマンスが向上します。
更新操作に対する応答時間の許容限度は、maxdirtycaheを使って調整することができます。たとえば、サーバ応答の許容限度が5秒で、ランダムディスク書き込み速度が毎秒20Mの場合、mazdirtycacheを20x5 = 100MBに設定します。ブロックキャッシュがこの量のダーティブロックをメモリ内に保持できることを確認して下さい。詳細については、セクション 5.2.2, _ndsdb.iniによるFLAIMキャッシュ設定の変更を参照してください。