Environment
eDirectory 9.x
eDirectory 8.x
eDirectory 8.x
Situation
How to you tune eDirectory for the best LDAP performance?
Resolution
Here are a few suggestions.
1. The LDAP server should hold a Master or Read Write replica of ALL partitions in the tree. There should be no Read Only or Subordinate Reference replicas on the server.
2. Optimize eDirectory cache on the server. In most cases the default eDirectory cache settings are fine. However if you have a large eDirectory database you may need to make changes to eDirectory Cache on the server for better performance.
3. Create indexes for the attributes that are in the filter for LDAP queries. This allows for efficient retrieval of object during searches without having to dredge the entire database each time. It will simply use the indexes to to find the objects.
To do this you first need to capture a trace of the LDAP queries that are occurring on your server. Configure LDAP tracing per Technical Information Document 7001461 - How to trace LDAP operations to the screen or log file. You should also include the tracing options to show information about index usage found in the Additional Note section.
Once you get the log, look in the Search requests,
4247951104 LDAP: [2018/05/01 13:01:21.910] Search request:
base: "o=mountain"
scope:2 dereference:0 sizelimit:2 timelimit:31 attrsonly:0
filter: "(&(objectClass=person)(cn=admin))"
attribute: "1.1"
specifically at the filter line. Below are a few various examples.
filter: "(&(objectClass=person)(cn=admin))"
filter: "(groupMembership=cn=SSPRAdmins,o=mountain)"
filter: "(&(objectClass=inetOrgPerson)(|(cn=*User1*)(givenName=*User1*)(sn=*User1*)(mail=*User1*)(workforceID=*User1*)))"
filter: "(&(objectClass=inetOrgPerson)(|(cn=*)(givenName=*)(sn=*)(mail=*)(workforceID=*)))"
Note what it is looking for in the filter: "(&(objectClass=person)(cn=admin))".
Specifically on the left and right of the equal (=) sign. To the left of the = is the LDAP attribute name. To the right of the = is the value it is looking for.
If there is a * to the right of the = sign, then the LDAP search is looking for any value in that attribute. Or to restate: any objects that have any value in the LDAP attribute name on the left of the = sign.
If there is a specific value defined, such as person or admin above to the right of the = sign, then the search is looking for only those objects which have the specific values in the attribute defined to the left of the = sign.
For best LDAP server performance, you should have an index on each attribute that you see being referenced in the filter line on a LDAP search. The type of index you create, depends upon if the search is looking for any value (*), or a specific value, such as person or admin in the example above.
Use Presence when a * is used in the query.
Use Value when a specific value is used in the query.
Indexes are created in iManager, on the server object running the LDAP Server that you are querying with LDAP. Edit the properties of the Server object in iManager and go to the Index Management tab.
Look for existing indexes that have the eDirectory attribute name that correlates to what you are seeing in the LDAP trace and the rule (Presence or Value) that you need for your queries. The Index name does not matter, only that there is an index on the attribute with the specific type of rule you need. Add indexes you need to the list to optimize the LDAP searches. You will note that the index you create is a user index, and will first start of in Pending state until the index is fully populated, then it will go to a online state.
Adding indexes for these attributes return LDAP searches in miliseconds compared to seconds / minutes, depending upon the database size and disk performance.
Additional Notes:
I. Attribute Names - No Spaces: The names you see for attributes in the LDAP trace may not be the same names you see for the eDirectory attributes. The most common difference is the ldap name may not have a space between the name you see in eDirectory. Such as groupMembership (ldap) Group Membership (eDirectory). They are the same attribute.
II. Attribute Names - Completely Different: You may not even see anything like the same attribute name in eDirectory that you see in the LDAP trace. This is possible as you can define a LDAP Attribute Mapping on the LDAP Group object the LDAP Server is using.
For example, in a LDAP trace you would see GroupID, which correlates to the GID attribute in eDirectory. If you needed to create an index for GroupID, then you would create an index on the eDirectory GID attribute.
III. Excessive indexes: Though indexes are essential for LDAP optimization. You should not create indexes for all attributes. Only create indexes for those attributes you are seeing used in LDAP queries. There is a cost benefit performance issue associated with indexes. Indexes save large amounts of time on queries, but they do have a cost associated with maintaining the index in eDirectory. So if you are not using an index then that cost should be avoided by removing the index or not creating it in the first place.
IV. Indexes are Server Specific. You need to create or copy a index on each server object you want to utilize the index for LDAP queries. Indexes are not tree-wide, nor replica-wide. They are server specific and associated with the eDirectory database on the server itself. So you need indexes on each server that responds to LDAP queries.
1. The LDAP server should hold a Master or Read Write replica of ALL partitions in the tree. There should be no Read Only or Subordinate Reference replicas on the server.
2. Optimize eDirectory cache on the server. In most cases the default eDirectory cache settings are fine. However if you have a large eDirectory database you may need to make changes to eDirectory Cache on the server for better performance.
3. Create indexes for the attributes that are in the filter for LDAP queries. This allows for efficient retrieval of object during searches without having to dredge the entire database each time. It will simply use the indexes to to find the objects.
To do this you first need to capture a trace of the LDAP queries that are occurring on your server. Configure LDAP tracing per Technical Information Document 7001461 - How to trace LDAP operations to the screen or log file. You should also include the tracing options to show information about index usage found in the Additional Note section.
Once you get the log, look in the Search requests,
4247951104 LDAP: [2018/05/01 13:01:21.910] Search request:
base: "o=mountain"
scope:2 dereference:0 sizelimit:2 timelimit:31 attrsonly:0
filter: "(&(objectClass=person)(cn=admin))"
attribute: "1.1"
specifically at the filter line. Below are a few various examples.
filter: "(&(objectClass=person)(cn=admin))"
filter: "(groupMembership=cn=SSPRAdmins,o=mountain)"
filter: "(&(objectClass=inetOrgPerson)(|(cn=*User1*)(givenName=*User1*)(sn=*User1*)(mail=*User1*)(workforceID=*User1*)))"
filter: "(&(objectClass=inetOrgPerson)(|(cn=*)(givenName=*)(sn=*)(mail=*)(workforceID=*)))"
Note what it is looking for in the filter: "(&(objectClass=person)(cn=admin))".
Specifically on the left and right of the equal (=) sign. To the left of the = is the LDAP attribute name. To the right of the = is the value it is looking for.
If there is a * to the right of the = sign, then the LDAP search is looking for any value in that attribute. Or to restate: any objects that have any value in the LDAP attribute name on the left of the = sign.
If there is a specific value defined, such as person or admin above to the right of the = sign, then the search is looking for only those objects which have the specific values in the attribute defined to the left of the = sign.
For best LDAP server performance, you should have an index on each attribute that you see being referenced in the filter line on a LDAP search. The type of index you create, depends upon if the search is looking for any value (*), or a specific value, such as person or admin in the example above.
Use Presence when a * is used in the query.
Use Value when a specific value is used in the query.
Indexes are created in iManager, on the server object running the LDAP Server that you are querying with LDAP. Edit the properties of the Server object in iManager and go to the Index Management tab.
Look for existing indexes that have the eDirectory attribute name that correlates to what you are seeing in the LDAP trace and the rule (Presence or Value) that you need for your queries. The Index name does not matter, only that there is an index on the attribute with the specific type of rule you need. Add indexes you need to the list to optimize the LDAP searches. You will note that the index you create is a user index, and will first start of in Pending state until the index is fully populated, then it will go to a online state.
Adding indexes for these attributes return LDAP searches in miliseconds compared to seconds / minutes, depending upon the database size and disk performance.
Additional Notes:
I. Attribute Names - No Spaces: The names you see for attributes in the LDAP trace may not be the same names you see for the eDirectory attributes. The most common difference is the ldap name may not have a space between the name you see in eDirectory. Such as groupMembership (ldap) Group Membership (eDirectory). They are the same attribute.
II. Attribute Names - Completely Different: You may not even see anything like the same attribute name in eDirectory that you see in the LDAP trace. This is possible as you can define a LDAP Attribute Mapping on the LDAP Group object the LDAP Server is using.
For example, in a LDAP trace you would see GroupID, which correlates to the GID attribute in eDirectory. If you needed to create an index for GroupID, then you would create an index on the eDirectory GID attribute.
III. Excessive indexes: Though indexes are essential for LDAP optimization. You should not create indexes for all attributes. Only create indexes for those attributes you are seeing used in LDAP queries. There is a cost benefit performance issue associated with indexes. Indexes save large amounts of time on queries, but they do have a cost associated with maintaining the index in eDirectory. So if you are not using an index then that cost should be avoided by removing the index or not creating it in the first place.
IV. Indexes are Server Specific. You need to create or copy a index on each server object you want to utilize the index for LDAP queries. Indexes are not tree-wide, nor replica-wide. They are server specific and associated with the eDirectory database on the server itself. So you need indexes on each server that responds to LDAP queries.