How do I ensure my eTrust Directory installation performs optimally?

Document ID : KB000055570
Last Modified Date : 14/02/2018
Show Technical Document Details

There are several areas to concentrate on to ensure your eTrust Directory deployment operates optimally - these areas can be grouped as a) Hardware Specific, b) Directory Specific and c) Application Specific. Let's consider and summarize what these areas are.

Hardware Specific

  1. RAM Memory

    This is key! A general rule of thumb to obtain best performance is to make as much RAM available on the machines hosting eTrust Directory as possible. RAM is comparatively cheap these days and the benefits of ensuring your system has RAM to spare will pay it's rewards in future times when eTrust Directory is deployed and running.

    RAM is key for both read and write operations to the directory - a high percentage of a write operation is actually memory based and not disk based. Also, for disks that utilize memory mapped I/O, ensuring enough RAM is available can add to write performance.

  2. Hard Disk

    Using a striped disk array (or RAID) will improve disk based performance (writing, logging) - related to this is that multiple hard disk spindles is key to hard disk performance.

  3. CPU

    Less important than RAM and hard disk but go for the best (quickest) you can afford. Multiple CPU's even better...

Directory Specific

  1. DXCache

    This is key! Utilize DXCache to greatly improve read/write performance. DXCache keeps a copy of indexed directory attributes in-memory which are used for all read operations and are wrote-through for all write operations (i.e. both in-memory and physical stores are updated).

    If you have followed 1) above - i.e. RAM memory is not a limitation, best practice advise is to cache all attributes. DXCache settings are defined on a DSA basis and configured in the DSA's server .dxi file. If memory allows, set cache-index = all-attributes.

    If memory is a restriction, you will need to identify appropriate attributes to cache and index - buy more/enough memory and this should not be something you need to concern yourself about

    See the r8.1 Administrator Guide, Chapter 3: General Administration -> Cache DSAs.

  2. Distribute Data

    One of the key differentiators between eTrust Directory and other directory products in the market is eTrust Directory's capability to distribute your data to separate physical locations. For example, this allows you to identify certain hot sub-trees in your DIT and ensure requests hitting that sub-tree are provided with optimal resources (memory, hardware).

    As a general rule of thumb, if you have or expect to have 10,000+ entries in your directory, there is probably no need to distribute your data across different machines. If you have or expect to have 100,000+ entries in your directory, you should probably consider distribution. If you have or expect to have 1,000,000+ entries, you should definitely be distributing your data.

    See the r8.1 Administrator Guide, Chapter 5: Distribution and DSP.

  3. Use One DSA Per Database

    Do not define multiple DSAs to access the same database - e.g. a read-only DSA and a read/write DSA. If you have the need to provide read-only access to a database for certain users, this would usually be for reporting or similar operations. If so, consider if the reporting data needs to be real-time? Consider implementing some automated procedure to copy the database at periodic times (e.g. every hour, every day) to another location and allowing the read-only access DSA to access the copied database only.

Application Specific

  1. Design a Rich (Deep) DIT Structure - not a Data Bucket!

    As a general rule of thumb, it is better to design a deeply nested DIT architecture than just using a flat namespace where all data is stored at the same level. Designing a rich/deep DIT structure allows directory searches and indexing to be optimized.

    However, when designing your DIT, don't over-design - if the way your organization functionally operates does not fit into a theorized DIT design, don't force it onto the organization!

  2. Optimize Application LDAP Queries

    A Directory is not a RDBMS database and to get the best out of querying a directory, some general application rules should be observed.

    • Only store attributes in an entry that are actually going to be used. For example, in a database system a record in a table may contain a TelephoneNumber field - when an insert or update command is made and no telephone number is defined, typical database behaviour may be to set the TelephoneNumber field to N/A (or some other dummy value). This is bad-practice in a directory - if an entry does not use an attribute, don't define it in the entry. Only store real data values for an attribute in a directory entry.

    • Ensure your end applications do not make superfluous data read operations - get the required data set in one read from the directory and use logic in the code to work with that returned data. Do not implement conditional logic that requires second or third reads from the database depending on matching a boolean data value returned on a first read - get all the data of interest up-front in one initial read.

    • For any LDAP requests, ensure that all requests are fully prefixed - this allows the directory to ensure it starts any searches at the appropriate location in the directory and doesn't need to trawl from the base.

  3. Schema Design

    When defining the schema you will use to store your directory data, consider the following:

    • Use standard attributes - the Directory is optimized to work with standard attributes.

    • Don't define unnecessary repetitive values. For example, if you have an attribute named PlatinumCreditCard and only 1% of your organization have this, don't define all users who don't have this entry to have a No value. Only define this attribute for those users who own or are assigned that entity (i.e. give them a Yes value for this attribute and don't define the entry for the 99% of users who don't have a Platinum card).

    • Don't define unnecessary object classes (i.e. parent classes) - for example don't define top -> person -> orgPerson -> iNetOrgPerson -> myOrgPerson - just define myOrgPerson.

  4. For Large User Groups Define Unique Prefix

    When working with a large number of users in a User Group, ensure their user name prefixes are as random and as different as possible. This will aide searching and indexing. For example, naming users usernumber0001, usernumber002, usernumber003 etc... is not good practice - ensuring at least the first 8 characters are as unique as possible will allow the Directory to index the data optimally.