|
| |
| Sun Java(TM) System Directory Server 5.2 2005Q1 Performance Tuning Guide | |
Chapter 7
Tuning Class of ServiceDirectory Server provides Class of Service (CoS) functionality to facilitate centralized management of common attribute values. For example, many users may share the same fax number as an attribute of their entries; CoS lets you store that number in one entry, then generate it for the other entries. As a result, you only have to keep track of the fax number in one place, but client applications can search for it on any entry to which it applies.
The disadvantage of CoS is the performance penalty paid for the convenience of having Directory Server generate attribute values for you. In many cases, the advantages of centralized management of common attribute values clearly outweigh the cost disadvantages. Yet it helps to have some idea how CoS works in order to make that comparison.
This chapter covers how Directory Server implements CoS to help you gauge whether a particular use of CoS fits your performance requirements. It includes the following sections:
How Class of Service WorksThis section takes a look at how CoS works from the inside. To gain a clear understanding of the functionality CoS provides and to find information on using CoS in your deployment, refer to the Directory Server Deployment Planning Guide. For step by step instructions on how to set up CoS, refer to the Directory Server Administration Guide.
Directory Server supports three types of CoS functionality: pointer CoS, indirect CoS, and classic CoS. For each type of CoS, template entries provide the actual attribute values, and definition entries specify the relationship between the template entries and the target entries on which Directory Server generates attribute values. The following sections cover CoS operation:
Pointer CoS
Pointer CoS definition entries point to a template entry holding the attribute value used. Recall also that a CoS definition entry targets all entries in the subtree where the definition is located. For pointer CoS, Directory Server therefore generates the same attribute value for all entries in the subtree. Figure 7-1 shows how Directory Server generates each CoS attribute value.
Figure 7-1 Pointer CoS Operation
As shown, pointer CoS attribute generation involves:
- Checking whether the entry is in the scope of the pointer CoS definition.
- Checking whether the object class(es) for the target entry allow that entry to hold the attribute specified by the pointer CoS definition.
In other words, if the pointer CoS definition provides for fax numbers, can the entry in question hold a fax number attribute?
If you turn nsslapd-schemacheck on cn=config to off, Directory Server skips this step.
- Generating the attribute value from the template entry onto the target entry.
As pointer CoS definitions directly identify template entries, Directory Server can cache attribute values to generate. Pointer CoS therefore typically has lower performance cost than indirect or classic CoS configurations involving the same number of CoS definitions.
Indirect CoS
Indirect CoS definition entries specify both the attribute to generate and the attribute in the target entry identifying the template entry. You might use Indirect CoS, for example, to generate fax numbers for employees in ou=People,dc=example,dc=com where fax number depends on building code. Figure 7-2 shows how Directory Server generates each CoS attribute value.
Figure 7-2 Indirect CoS Operation
As shown, indirect CoS attribute generation involves:
- Checking whether the entry is in the scope of the indirect CoS definition.
- Checking whether the object class(es) for the target entry allow that entry to hold the attribute specified by the indirect CoS definition.
If you turn nsslapd-schemacheck on cn=config to off, Directory Server skips this step.
- Retrieving the value of the target entry attribute identified by the CoS indirect specifier attribute of the definition entry.
This attribute value is the DN of the template entry.
- Looking up the template entry using the attribute value retrieved in Step 3.
- Generating the attribute value from the template entry onto the target entry.
Directory Server can cache indirect CoS definition entries efficiently. It does not cache indirect CoS template entries in any special way. As template indirect CoS template entries depend entirely on target entry attribute values, the cost of maintaining such a cache could be prohibitively expensive. Looking up template entries can of course work faster if Directory Server retrieves them from entry cache in RAM, rather than from disk storage.
Indirect CoS typically has higher performance cost than both pointer CoS and classic CoS for configurations involving the same number of CoS definitions.
Classic CoS
Classic CoS definition entries provide similar functionality to indirect CoS definition entries. Instead of specifying a target entry attribute that then fully identifies the template entry by DN, however, classic CoS definition entries specify the base DN of the template entry and the CoS specifier attribute on the target entry that further identifies the template entry under the base DN that holds the CoS attribute value to generate. You might use classic CoS, for example, to generate one set of fax numbers for managers, fax machines used for confidential information perhaps, and another set of fax numbers for other employees, where fax number depends on the building code.
As each classic CoS definition entry specifies a base DN to identify template entries, each classic CoS definition potentially relates to a large number of templates that Directory Server can identify in advance. Directory Server caches the list of templates for each classic CoS definition entry.
To optimize the cache structure for fast lookup, Directory Server maintains a hash when more than 10 templates correspond to a definition. Directory Server builds hash keys from the values of the attributes identified as cosSpecifier attribute values (the RDNs of the template entries). To avoid clashes, where several templates correspond to the same hash key, ensure the RDNs of the template entries are significantly different. You can monitor CoS through CoS monitoring attributes described in the Directory Server Administration Reference.
Figure 7-3 shows how Directory Server generates each CoS attribute value.
Figure 7-3 Classic CoS Operation
As shown, classic CoS attribute generation involves:
- Checking whether the entry is in the scope of the classic CoS definition.
- Checking whether the object class(es) for the target entry allow that entry to hold the attribute specified by the classic CoS definition.
If you turn nsslapd-schemacheck on cn=config to off, Directory Server skips this step.
- Determining the template entry DN using the base DN specified in the definition entry and the specifier value in the target entry.
- Looking up the template entry in the list of template entries under the base DN specified in the definition entry.
- Generating the attribute value from the template entry onto the target entry.
Each classic CoS attribute value generation therefore requires several lookups. The performance cost of classic CoS typically costs less than indirect CoS and more than pointer CoS configurations involving the same number of CoS definitions.
CoS Ambiguity
Nothing in Directory Server prevents you from creating multiple CoS definition entries that each generate a value for the same single-valued attribute on a given target entry. The Directory Server Administration Guide explains that when multiple definitions of identical CoS priority can apply Directory Server picks one arbitrarily. By default, unless you specify otherwise, all CoS definitions have the same priority.
Directory Server logs warning messages when forced to make an arbitrary distinction among multiple applicable definition entries. This logging capability was not provided in earlier versions of Directory Server. Such warning messages takes the form:
Definition defDN1 and definition defDN2 compete to provide attribute 'type' at priority level
You can also configure Directory Server to log informational messages when it is forced to make an arbitrary distinction among multiple, potentially applicable definition entries. To do so, set the log level high enough to include informational messages from plug-ins. Note that this can result in a heavy logging load, so you might not want to set logging that high on a production server instance. The content of informational messages takes the following form:
Definition defDN1 and definition defDN2 potentially compete to provide attribute 'type' at priority level
You can then choose whether to resolve such cases of CoS ambiguity by setting CoS priorities appropriately on the definition entries.
Implementing CoS for Best PerformanceThis section examines some implications of how CoS works on the ways you might naturally use CoS functionality as intended, and avoid performance pitfalls.
- Avoid Thousands of CoS Definitions
When Many Entries Share the Same Value
CoS provides big benefits for relatively low cost when you need the same attribute value to appear on a large number of entries in a subtree.
Imagine, for example, a directory for MyCompany, Inc. in which every user entry under ou=People has a companyName attribute. Contractors have real values for companyName attributes on their entries, but all regular employees have a single CoS-generated value, MyCompany, Inc., for companyName. Figure 7-4 demonstrates this with pointer CoS. Notice here that CoS generates companyName values for all permanent employees without overriding real, not CoS generated, companyName values stored for contractor employees.
Figure 7-4 Generating CompanyName With Pointer CoS
In cases where many, many entries share the same value, pointer CoS works particularly well. The ease of maintaining companyName for permanent employees clearly offsets the additional processing cost of generating attribute values. Deep directory information trees (DIT) tend to bring entries sharing common characteristics together. Pointer CoS can often be used in deep DITs to generate common attribute values by placing CoS definitions at appropriate branches in the tree.
When Entries Have Natural Relationships
CoS also provides big data administration benefits where directory data has natural relationships.
Consider an enterprise directory for example in which every employee has a manager, and every employee shares a mail stop and fax number with the nearest administrative assistant. Figure 7-5 and Figure 7-6 demonstrate use of indirect CoS to retrieve department number from the manager entry and mail stop and fax number from the administrative assistant entry, respectively.
Figure 7-5 Generating DepartmentNumber With Indirect CoS
In this implementation, manager's entries have real values for departmentNumber, and these real values override generated values. Directory Server does not generate attribute values from CoS generated attribute values. As a result, for the example shown in Figure 7-5 department number attribute values need to be managed only on manager entries. Likewise, for the example shown in Figure 7-6 mail stop and fax number attributes need to be managed only on administrative assistants' entries.
Figure 7-6 Generating Mail Stop and Fax Number With Indirect CoS
Notice that a single CoS definition entry can be used to exploit relationships such as these for many different entries in the directory.
Another natural relationship is service level. Consider an Internet service provider offering customers standard, silver, gold, platinum packages. A customer's disk quota, number of mailboxes, and rights to prepaid support levels depends on the service level purchased. Figure 7-7 demonstrates how a classic CoS scheme enables this.
Figure 7-7 Generating Service Level Data With Classic CoS
Notice one CoS definition may be associated with multiple CoS template entries.
Avoid Thousands of CoS Definitions
As described in Classic CoS, Directory Server optimizes for the case where one classic CoS definition entry is associated with multiple CoS template entries. Directory Server does not, however, optimize for the case where many, many CoS definitions potentially apply. Instead, Directory Server checks each CoS definition to determine whether it applies. This behavior leads to performance problems when you define thousands of CoS definitions.
This situation can arise in a modified version of the example shown in Figure 7-7. Consider an Internet service provider offering customers delegated administration of their customers' service level. Each customer provides definition entries for standard, silver, gold, and platinum service levels. Ramping up to 1000 customers therefore means creating 1000 classic CoS definitions, with the consequent performance hit as Directory Server runs through the list of 1000 CoS definitions to determine which apply. If you must use CoS in this sort of situation, consider indirect CoS, where customers' customers' entries identify the entries defining their class of service allotments.
With or without thousands of CoS definitions, once you start approaching the limit of having different CoS schemes for every target entry or two, you are better off paying the management price of updating the real values, thereby gaining the performance price of reading real, rather than CoS-generated values.
