Attribute caching

Edit online

You must identify the attributes that are most referenced and must cache them in the attribute cache to reduce the search operation time.

To determine which attributes to cache, you must experiment by adding some or all of the attributes that are listed in cached_attribute_candidate_hit to the attribute cache. Then, run your workload and measure the differences in operations per second. For information about the cached_attribute_candidate_hit attribute, see Search with the cn=monitor base.

Note: Choosing to cache the member, uniquemember, or ibm-membergroup attributes can lead to reduced performance with the delete and modrdn operations. If you are deleting or renaming an entry that is a member of many groups, then the attribute caches must be updated. The update must be reflected on every group in which the entry was a member. The additional processing can lead to slower performance with search or update operations.

You can retrieve information about attributes that are cached, their individual sizes in KB, and their hit counts by running the ldapsearch command with the cn=monitor base. You can retrieve up to 10 attributes that are most used in the search filters. The attribute cache manager must be able to process these attributes, which are not yet cached. Use a combination of the search output from the cn=monitor searches and different types of searches that your applications use to determine which attributes to cache.

Examples

Example 1:

If you do not configure a directory server for attribute caching, the following results are returned by the ldapsearch command with the cn=monitor parameter:

ldapsearch -h ldaphost -p port -s base -b cn=monitor objectclass=* \
	cached_attribute_total_size cached_attribute_configured_size \
  cached_attribute_hit cached_attribute_size \
  cached_attribute_candidate_hit 
cn=monitor 
cached_attribute_total_size=0 
cached_attribute_configured_size=1200 
cached_attribute_candidate_hit=mail:50000 
cached_attribute_candidate_hit=uid:45000 
cached_attribute_candidate_hit=givenname:500 
cached_attribute_candidate_hit=sn:200

Based on the result that is returned by the ldapsearch search, you can consider caching the uid and mail attributes. Even though, givenname and sn are used in search filters that are resolved by the attribute cache manager. If these attributes are cached, their hit counts are low in comparison to the uid and mail attributes. Therefore, caching the givenname and sn attributes in memory is not appropriate.

After you cache the uid and mail attributes, rerun the application or performance test. You must run ldapsearch for cn=monitor again to determine whether there is enough memory to cache both the attributes. If there is not enough memory, then more memory must be configured or the least-used attribute must be removed from the list of attributes to cache.

Example 2:

Consider that the attribute cache is configured with the givenname and sn attributes. The cache hit count for objectclass is high. Also, the cache hit rates for uid and mail are high.

ldapsearch -h ldaphost -p port -s base -b cn=monitor objectclass=* \
cached_attribute_total_size cached_attribute_configured_size \
cached_attribute_hit cached_attribute_size cached_attribute_candidate_hit 
cn=monitor 
cached_attribute_total_size=1000 
cached_attribute_configured_size=1200 
cached_attribute_hit=givenname:500 
cached_attribute_size=givenname:300 
cached_attribute_hit=sn:200 
cached_attribute_size=sn:400 
cached_attribute_candidate_hit=objectclass:110000 
cached_attribute_candidate_hit=mail:90000 
cached_attribute_candidate_hit=uid:85000 
cached_attribute_candidate_hit=workloc:25000

The cached_attribute_total_size attributes specifies the amount of memory that is used by the directory attribute cache in KB. It includes the additional memory that is used to manage the cache that is not charged to the individual attribute caches. The total is larger than the sum of the memory that is used by all the individual attribute caches.

In the example, givenname and sn are not good choices for caching because of their low hit count in comparison to the other attributes. From the search results, objectclass is a good choice for caching. The uid and mail attributes are also good choice for caching.

Configure attribute cache to cache the objectclass, uid and mail attributes and rerun the performance tests to verify whether the performance results are as expected. If the cn=monitor search returns the results with a hit count much lesser after caching objectclass compared to when it was a candidate.

ldapsearch -h ldaphost -p port -s base -b cn=monitor objectclass=* \
cached_attribute_total_size cached_attribute_configured_size 
cached_attribute_hit cached_attribute_size cached_attribute_candidate_hit 
cn=monitor 
cached_attribute_total_size=1000 
cached_attribute_configured_size=1200 
cached_attribute_hit=objectclass:10000 
cached_attribute_size=objectclass:750 
cached_attribute_candidate_hit=mail:90000 
cached_attribute_candidate_hit=uid:85000 
cached_attribute_candidate_hit=workloc:25000 
cached_attribute_candidate_hit=givenname:300 
cached_attribute_candidate_hit=sn:200

If you observe unexpected results, you can consider the following reasons:

The objectclass attribute table is large in comparison to the other attribute tables. Even though objectclass, uid and mail are cached, objectclass is the only attribute that fit within the maximum memory that is set for attribute caching.
You must analysis the search filters used by your application. In the example, the results shows that objectclass is not used in search filters. The attribute cache manager might not resolve many filters because all the attributes in the filter are not cached. A combination of the cn=monitor search result and analysis of the filters helps you to determine which attributes to cache. The search filters and the number of hits are shown here:
```
(objectclass=*)10000 hits 
(givenname=*)300 hits 
(sn=*)200 hits 
(mail=*)	50000 hits 
(uid=*)45000 hits 
(workloc=*5000 hits 
(&(objectclass=person)(mail=*))40000 hits 
(&(objectclass=person)(uid=*))40000 hits 
(&(objectclass=person)(workloc=*))20000 hits
```

From the search filter results, when the objectclass attribute is specified alone in the filter the attribute gets 10000 hits. Therefore, if the only attribute cached is objectclass, the attribute cache manager can resolve 10000 out of the 210500 total search filters. If the server is configured to have enough memory to hold both the objectclass and mail attributes, 100000 of the search filters can be resolved by the attribute cache manager. If objectclass, uid and mail are all configured and enough memory is available, 185000 of the search filters can be resolved by the attribute cache manager. However, if memory is constrained and only one attribute can be cached, the best choice is mail with 50000 hits. If both uid and mail can be cached, 95000 filters can be resolved by the attribute cache manager. It is almost as many hits as caching objectclass and mail instead.

For example, assume that caching uid and mail uses less memory than caching objectclass and mail. In such cases, caching uid and mail instead of objectclass and mail might be a better choice if enough memory is not available on the server. Therefore, it is necessary to understand and consider the types of search filters that are used by an application to determine the appropriate attributes to cache. You must also consider the amount of memory available on the server to use for attribute caching.