MIIS 2003 Capacity Planning - Additional Performance Considerations

Article
10/05/2010

Applies To: Windows Server 2003 with SP1

Previous Sections in This Guide

Other Capacity and Performance Considerations

Due to the way MIIS 2003 interacts with so many different and diverse systems, it is difficult to create a single, definitive source for capacity and performance related information. While the scope of this document is focused mostly on the server hosting MIIS 2003, many other capacity and performance-related factors should be considered.

This section presents a brief discussion on some of those factors. It does not present specific recommendations or include any test data. This section is intended to present additional factors that are commonly encountered in MIIS 2003 deployments.

MIIS 2003 Implementation

Many of the basic design decisions you make about the design of your MIIS 2003 environment can have a long-term effect on performance. MIIS 2003 creates a database of all the identity related data it has been configured to manage. Many operations it performs involve searching through the stored data and performing some operation on each object. A database that contains a large amount of extra, non-essential data can adversely affect search performance. While many design decisions are made based on storage capacity, you should also consider the impact they will have on performance.

Metaverse Design

During metaverse design, two opposing options for populating the metaverse are often considered. The first approach minimizes metaverse growth by dictating that only the objects and attributes that are to be managed by MIIS 2003 are imported into the metaverse. The idea underlying this approach is that the metaverse should only be populated with data that MIIS 2003 is currently responsible for managing. One advantage of this approach is that the size of the metaverse remains as small as possible. This results in better search performance and faster convergence if the synchronization rules are changed. One disadvantage is that future growth to support the management of additional objects and attributes might be more difficult to implement.

An alternative approach dictates that you examine your environment and determine which objects, and their associated attributes, you want to manage. You also include any objects and attributes that you think might be managed by MIIS 2003 in the future. This approach front loads the metaverse and provides a more stable base for growth. However, the additional data might impact the performance of database-intensive operations such as metaverse searches and resynchronization after changes to synchronization rules.

Attribute Types

Performance is also impacted by the number and type of attributes you choose to store in the metaverse. Two types in particular, multivalued and indexed attributes, have significant performance implications.

Multivalued attributes are single attributes that can contain more than one value. For example, a group object might have a single attribute called Membership. If that group has 100 members, that attribute might contain 100 different values. If your deployment utilizes many multivalued attributes, your metaverse might contain a lot more information than is apparent. This size can affect search and synchronization operations.

Searches that involve multi-valued attributes also can affect performance. The values stored in a multivalued attribute are actually stored by concatenating the individual values together into a single string. This makes it easy to detect any changes made because the new string can be compared to the old string that is stored in the metaverse. However, the use of a single string makes search operations more complex. The values are not sorted before they are concatenated into the string for storage. Therefore, when a search operation is initiated, each string must be parsed to get the individual values, and then the values must be sorted, before the search occurs. The parsing and sorting causes additional overhead that results in slower performance during search operations.

Indexed attributes can be used for more efficient search and join operations, thereby increasing the performance of those operations. The disadvantage is that indexed attributes utilize slightly more space in the database. But this is a negligible consideration especially when compared to the improved search and join performance gained by the use of the index.

Rules Extensions

Rules extensions are customized procedures written to handle special requirements of a customer's environment. They are customized .NET assemblies written in VB.NET or C# to augment the functionality of MIIS 2003. Care must be taken to prevent the introduction of performance issues into your MIIS 2003 environment when implementing your rules extensions.

Optimize your code

Put as much thought into optimizing any rules extension code you develop as you put into selecting an optimal hardware configuration to maximize the performance of your MIIS 2003 server.

Make sure you follow good coding habits. Try to avoid unnecessary decisions and function calls. When examining code examples posted on newsgroups and discussion lists it appears that many authors are intent on solving a particular problem but completely ignore any performance considerations of the code they write. If these examples are copied and implemented into production environments many would have a seriously negative impact on performance.

Logical Operators

Thoroughly test any rules extension code you develop. Ensure that it is functioning properly and producing the desired result, and that it is performing as expected. For example, VB.NET does not handle some logical operations in the manner some developers expect. Consider the two logical operators And and Or. In many programming languages, during the processing of a statement such as:

If ConditionX or ConditionY then StatementZ

ConditionY will not be evaluated if ConditionX is true. The nature of the Or operator is such that if one condition is true, then the entire statement evaluates to true. If the first condition evaluates to true, the second condition is not evaluated because the whole statement is true regardless of the second condition. This type of behavior helps optimize the code, especially if the second condition involves a function call.

VB.NET does not process the Or statement in this manner. Regardless of how the first condition is evaluated, VB.NET still processes the second condition.

A new operator called OrElse has been introduced so that VB.NET can support this functionality. Using the OrElse operator for this type of decision will produce code that runs more efficiently but still behaves in an expected fashion. When you consider the implications of this small change in an MIIS 2003 environment, the potential performance ramifications can be significant. Consider the following statement:

If ConditionX or ConditionY then StatementZ

where ConditionY requires a function call that requires an operation such as a metaverse search. Each time this statement is processed, a metaverse search occurs even if ConditionX has already evaluated as true and there is no need to evaluate ConditionY. Now think about the ramifications of this if this line of code is called for each object in the metaverse and you are processing a million objects. Simply using the OrElse operator instead solves this problem and provides much more efficient code. Similar efficiencies might be gained by replacing the And operator with the new operator AndAlso.

This is an example where code you develop could be producing the proper output but it is not performing as efficiently as you expect. Extra time spent making sure the code is as efficient as possible can have significant rewards.

IsPresent

You can increase code efficiency by skipping blocks of code that deal with attributes that have not been initialized. Many code samples assume that all attributes are present and make calls based on that assumption. IsPresent is a property that indicates whether or not an attribute exists as part of an object. Verifying that an attribute is present before calling the code to process it will make your code run more efficiently, reduce errors (especially in more complicated implementations) and improve performance.

Utils.FindMVEntry

Avoid using Utils.FindMVEntry whenever possible. This will initiate a query against the metaverse which can result in slowing down the synchronization process. If you need to use this function then use it with indexed attributes.

Exception Handling

Structured exception handling might also be missing from code samples that are leveraged for production environments. Using the Exception class in conjunction with TRY CATCH statements allows you to manage control of your code even when unexpected events occur. Whereas the default behavior may be to attempt to process each object and record an error if an exception occurs, structured exception handling can be used to solve the problem causing the error. This can be preferable to recording an error message in a log or terminating the process altogether so no additional time is wasted by repeatedly recording an error message while failures continue to occur for each object processed.

Calling External Processes

Another coding convention to avoid is writing extension code that makes calls to systems that are external to MIIS 2003. For example, avoid practices such as calls to Active Directory to see if a user account already exists before processing some provisioning code or code that sends e-mail to someone if some event occurs while the extension code is still being processed. While this type of functionality can help solve some administrative processes, they can also reduce performance of the MIIS 2003 environment. Consider what would happen if the system being called was unavailable during the synchronization process, or only had intermittent connectivity. Instead, consider how this type of functionality can be managed entirely within MIIS 2003.

Management Agent Behavior

Make sure you understand everything a management agent is doing and how it will impact your environment before deploying it to your production environment. Some management agents require the addition of new object types to the metaverse and some have a significant amount of code in their rules extensions. Set up a test environment and deploy the new management agent so you can anticipate the impact on performance before implementing it in your production environment.

Database Considerations

Although this document presents results from limited testing of database performance issues, issues that pertain to database size and the workload on the database server also need to be considered.

Run History

The number of objects and attributes you decide to store in the metaverse is not the only factor that contributes to the size requirements of the MIIS 2003 database. Another significant contributing factor is MIIS 2003 run profile history.

Each time a run profile is processed, MIIS 2003 compiles a detailed report that lists the changes made to each object and attribute. This report is called the run history and is stored in the MIIS 2003 database. Repeated staging and synchronization operations that involve many objects and attributes can result in considerable space being consumed by the storage of run history information.

The MIIS Resource Tool Kit 2.0 (https://go.microsoft.com/fwlink/?LinkId=30738) contains a command line tool called MIISClearRunHistory that can be used to clear run history records from the database. This tool can be scheduled to run periodically and clear a range of run history records from the database. The number of records you clear and the frequency you run the tool will be determined by your reporting requirements and any database size restrictions.

Server Workload

One other performance consideration for the MIIS 2003 database is the workload of the server that hosts it. As discussed in the summary of the database tests earlier in this document, many organizations maintain their database servers in a centralized location for management and security reasons. In these scenarios, the database server is not likely controlled by the MIIS 2003 administrators.

Make sure that service levels around database server performance are agreed upon and maintained because they directly impact the performance of the MIIS 2003 environment. If the database servers become too busy serving other database clients throughout the organization, the performance of MIIS 2003 is degraded.

External Considerations

The environment outside of MIIS 2003 must also be considered for performance issues, both from the perspective of how it impacts MIIS 2003 and how MIIS 2003 impacts that environment. Implementing MIIS 2003 requires integrating environments, not just adding another. Due to this integrated relationship, anything that happens in one environment has the potential to affect the other environments managed by MIIS 2003. This includes planned activities, such as backup operations, as well as unplanned activities such as outages and disaster recovery operations.

Many of the data sources that MIIS 2003 interacts with are servers that are most likely providing services to other clients on the network. If they are overloaded, their response times to MIIS 2003 will be diminished and adversely affect the performance of the MIIS 2003 environment.

This particular problem also applies to MIIS 2003 and the requests it sends to the data sources. If MIIS 2003 attempts to stage a large number of objects, it might impact the performance of the data source server such that other clients using services from that server will start experiencing performance problems.

Two examples of data sources that are susceptible to both these issues are servers hosting Active Directory and Microsoft Exchange. Servers hosting these services are almost always mission-critical servers with many clients depending on the services they provide.

Make sure you consider the impact that staging 100,000 user objects might have on the domain controller that hosts Active Directory or the impact on the Exchange server of synchronizing global address lists for 50,000 contacts. Of less significance but still worth mentioning are network bandwidth considerations. In addition to routine e-mail traffic, Active Directory replication traffic, and client authentication traffic on the network, MIIS 2003 staging operations result in data being sent across the network. If a million objects are being staged, this will amount to a significant amount of traffic. Although communication across a slow link is not a recommended configuration for MIIS 2003, it may be necessary due to other limitations in the environment. In this situation, network bandwidth might be the most important consideration of all performance issues.

When integrating servers of this type into an MIIS 2003 environment, make sure that service level agreements are in place for both the well being of the MIIS 2003 environment and the well being of the data sources. Also perform adequate testing. These steps will help ensure that any impact on the performance of these servers is anticipated and steps have been taken to maintain service levels.

Hardware Considerations

Two additional considerations for the performance of the server platform that hosts MIIS 2003 are hyper-threaded processors and 64-bit platforms. We did not have an opportunity to test the affect of hyper-threading on performance for the tests presented in this document. It is assumed that you would see increased performance on a platform utilizing hyper-threaded processors, but we have no data to indicate how much of a benefit would be realized.

Regarding 64-bit platforms, currently MIIS 2003 is a 32-bit based application, so it is not likely any significant performance would be seen by deploying it on a 64-bit platform. Platforms of this type were not tested.