Establish a baseline or benchmark
It can be very useful to gather a performance baseline in order to be able to be able to better provide a contrast against any issues which might be encountered. Active Roles has PerfMon counters which can be very useful for this and for troubleshooting any performance issues.
Resources on the host server
As a general rule, a real-world deployment of the Windows operating system requires at least 2GB of RAM. In addition, each of the Active Roles components should be allocated at least 1GB of RAM. Therefore, if a server is hosting the Active Roles Service as well as the Web Interface, at least 4GB of RAM should be allocated. This would be sufficient for Active Roles to manage a small to medium environment - thousands of Active Directory objects could possibly be managed comfortably. Larger environments will notice significant performance issues in such a configuration. Extremely large environments, with Active Directory objects in the tens or hundreds of thousands, may encounter out-of-memory errors or outright crashes.
SQL Server Considerations
Having a dedicated SQL instance (one hosting only Active Roles databases) is always recommended.
Microsoft SQL is a resource-intensive application, and will typically consume any available memory on its host server.
To avoid SQL consuming all available memory and negatively impacting performance of the host server, the maximum memory available to SQL should be capped at no more than 2GB less than the total amount of available RAM as per this Microsoft resource. For example, if the Windows host has 16GB of RAM allocated, then a dedicated SQL instance on a dedicated SQL server host should be capped at 14GB.
Active Roles Administrative Service and SQL co-location
In labs, pre-production environments, or very small (e.g. 1000 managed objects or less) production environments, it may be possible to have a dedicated SQL instance hosted on the same machine which is hosting Active Roles. In larger production environments, separate dedicated hosts for the Administrative Service and SQL server are recommended. This is especially true for environments with tens of thousands of managed objects.
Other Windows Host Configuration Considerations
The Windows page file settings on the host server can also negatively impact performance if they are set too low. As per this Microsoft resource, the minimum page file size should be equal to the amount of RAM present on the host server, and the maximum size should be three times the amount of RAM present.
Latency to the environment
Active Roles is most sensitive to latency on communications to the SQL Server and to the associated Global Catalog server. Ideally, these resources would be in same site, with latency less than 1ms.
Cached information from before a change in the environment
Active Roles has a few different places where it caches environmental information. If the environment changes significantly (Active Directory schema or functional level updates, Microsoft SQL or Microsoft Exchange major version change, etc.) then this cache may contain obsolete information which negatively impacts performance.
Follow all steps in this reference in order to clear all of these caches.
"Expensive" Script calls
There are a few calls within scripts which should be used with caution, as they have the potential to significantly increase computational overhead. Be very careful when using policy scripts with the following triggers:
Any PowerShell scripts which are run by Active Roles should avoid the use of the Exit cmdlet when terminating. This call will actually force the Active Roles PowerShell runspace to terminate and reload. It is recommended to instead use Return to end a script.
The Active Roles System Summary will contain an export of all scripts. This file can be searched for instances of these functions or cmdlets - this can help with large or complicated environments with many script modules.
If PerfMon logs indicate that Script module average execution time is a potential performance bottleneck, this could also indicate poor performance when connecting to or working with Microsoft Exchange. When working with Microsoft Exchange 2010, it is an optional configuration to use Remote PowerShell when working with Microsoft Exchange - in all later versions of Microsoft Exchange, it is the only option. These Remote PowerShell calls are included in all Active Roles Script Module performance counters.