Performance Tuning Options in Novell eDirectory

• Indexing

Indexing can be a good way to speed up queries. The Indexes are viewed and managed using iManager by modifying the NCP Server object. From the eDirectory ndstrace data analysed it can be seen that objects are located within milliseconds using an index.

• Cache

The eDirectory database cache has a number of options for optimisation. The recommendations are dependent on the server operating system used.

eDirectory database cache is divided into two types, entry and block cache. Entry cache is where individual objects are cached, objects could be cached more than once. Block cache is a block of database data, which may contain data relating to more than one object.

 

Using Linux and Reiser, the block cache could be dropped to zero to allow Reiser to handle block caching. This increases eDirectory performance three-fold.

 

FLAIM DB Cache its good to go for 1GB of cache with 80% block for heavy write environments, 20% block for heavy Read environments, and 50% with equal read and write environments.

Note: Stream files are not cached by eDirectory. When this data is read it will always be retrieved from the file system.

• LDAP Search Parameters

Generally we ignore the below parameters. But, if we need a very good throughput and low reponsetimes sizelimit and time limit are good parameters which can be optimized.

a. searchSizeLimit

The maximum number of entries that the LDAP server will return to an LDAP client in response to a search. A value of 0 (zero) indicates no limit.

b. searchTimeLimit

The maximum number of seconds after which an LDAP search will be timed out by the LDAP server. A value of 0 (zero) indicates no limit.

The eDirectory engine will continue searching for and returning data after the client has already abandoned the LDAP request. These parameter values help to prevent inappropriate use of the LDAP service.

c. Scope Search

Take care of the scope search. Dont go for SUB Scope when scope ONE will work.

d. Attributes Returned
Only return the attributes required for the current query. Returning all attributes will require more eDirectory cache, LDAP Server CPU time, Data Layer API processing and increase LAN traffic.

e. Search Criteria

Search criteria is not that important in eDirectory.

• Good server hardware

Fast kit will make the difference between milliseconds and seconds.

• Good operating system

The operating system determine what tuning options are practical and therefore available. Using 64-bit Linux with reiser and setting the eDirectory block cache to zero will provide the best performance.

• Efficient monitoring and tracing

Sometimes ndstrace is the best option, in these cases care should be taken to ensure that only the filters required are used. The more details the log will contain the harder the eDirectory service must work to provide this. In testing this additional load added ~20% to the CPU usage of ndsd.