4.1 FLAIM Database

Cache sizing is arguably the most important factor affecting the overall performance of eDirectory. The greater the number of items (blocks and entries) that can be cached, the better the overall performance is. The percentage of times that the blocks or entries are found in the cache is called the hit ratio. A higher ratio results in better performance. iMonitor can be used to view the hit ratio.

The block cache is most useful for update operations. The entry cache is most useful for operations that performs a base-scoped search for an entry. However, both one-level and sub-tree scoped searches use the entry cache as well as the block cache. The block cache is used to retrieve indexes. Create the right type of indexes as necessary, for more information see Choosing Indexes.

A fault in the block cache can result in a disk read operation. Disk reads are always expensive, but they can be avoided if a block is retrieved from the filesystem cache.

The amount of memory required to cache the complete database in the block cache is nearly the size of the database on the disk, and the amount of memory required to cache the complete database in the entry cache is nearly two to four times the database size on the disk. When you have less memory on a system, try a smaller entry cache and a much larger block or filesystem cache.

If reads are localized to a set of entries in the directory, you should increase the entry cache as long as it results in an improved entry cache hit ratio.

If the read pattern is completely random and the DIB is much larger than the available RAM, you should have a larger block cache or a filesystem cache than the entry cache.

Any method you use to tune eDirectory for an improved performance needs empirical testing. A good ratio of entry to block cache for search-intensive environments is 2:1 ratio. Ensure that sufficient memory is left for other processes. Avoid page swapping even if it means reducing the FLAIM cache sizes.

Because FLAIM provides preallocated caching, memory allocated to the eDirectory cache is never fragmented by the native operating system memory manager.

4.1.1 Choosing Indexes

Indexes are meant to improve the one-level or sub-tree scoped search performance. Dynamic groups also use one-level or sub-tree scoped searches. Indexes are not used for base-scoped searches.

Because a Presence index does not differentiate between present and not present (deleted) values, it is mainly used for internal purpose. If applications run a Presence type search query, this index is never used, so applications should not have Presence indexes created for them.

Applications can create a Value index for an attribute, which is sufficient for most of the searches. FLAIM can use a Value index for performing both Presence as well as Substring searches on the attributes.

A Substring index can significantly decelerate the updates performed on an attribute. The number of index blocks required to support a Substring index is quite large compared to the Value index. This means more block cache is required to cache them. Create a Substring index only when necessary. A Value index should suffice for most searches. However, if Substring searches do not yield acceptable performance with a Value index, you can create a Substring index on those attributes.

If a search operation takes a long time to complete despite the chosen index, you might introduce a newer value index on one of the attributes of the search filter. Pick the attribute that yields best results when indexed.

4.1.2 Tuning for Updates

The block cache is most useful for update operations. Indexes also reside in the block cache. Although indexes help in faster searches, having too many indexes keeps the server busy maintaining them. Indexes are modified if attribute values are modified, added, or deleted. During large upload operations, indexes can be disabled for faster upload.

Having the RFL directory on a different disk than the DIB directory improves performance.

An acceptable limit for response time for an update operation can be controlled by using the maxdirtycache. For example, if an acceptable limit for the server response is 5 seconds and random disk write speed is 20 MB per second, then the maxdirtycache should be set as 20x5 = 100 MB. Ensure that the block cache can hold these dirty blocks in memory. See Modifying FLAIM Cache Settings through _ndsdb.ini for more information.