Unfortunately, there is not much written that documents AD performance issues and how to use these counters. This TechNet overview article is a good place to start. There are two main objects to monitor:

1. Information related to the NTDS Object:

http://technet2.microsoft.com/windowsserver/en/library/6a2abace-5fab-49f0-8c6d-5daea891a5f71033.mspx?mfr=true

2. Information related to the Database Object:

http://technet2.microsoft.com/windowsserver/en/library/26bfde1e-7938-4573-b12f-6e4e9cedf4a51033.mspx?mfr=true

The following represents Microsoft’s recommendations when monitoring Domain Controllers:

http://technet2.microsoft.com/windowsserver/en/library/c5d72b6f-5974-4263-b29f-2eece0ab44371033.mspx?mfr=true

It will at least help you get acquainted with the basic terminology that AD uses.

Figure 1.
This filter definition instructs the collector to report Module instances only for the dllhost.exe and svchost.exe processes. In addition, only the specific Module instances named will be collected, which is the information needed to identify the application running inside these container processes.

On a typical Windows XP or Windows Server machine, you will several instances of the svchost container processor executing. svchost is a container process that hosts various system services. Different services run in different copies of svchost depending on their security requirements. You will see them identified with different Used Names in Task Manager, for example. For instance, services that do not need network access with execute inside a copy of svchost that executes under the security profile associated with local service. Other copies of svchost run under the SYSTEM or NETWORK SERVICE. In order to figure out which services are running inside which copy of svchost, use this Module filter definition to identify modules that are unique to a specific instance of svchost.
With this filter definition active, we expect to report:

1. one instance of the Module Object for browser.dll associated with a specific svchost.exe parent process and
2. another instance of the Module Object for rpcss.dll associated with a different svchost.exe parent
3. another instance of the Module Object for regsvc.dll associated with a different svchost.exe parent
4. another instance of the Module Object for winspool.drv associated with a different svchost.exe parent

Using the SAS Merge function, you could then report process level statistics for the svchost container process by application.

Similarly, for dllhost.exe, filtering on wam.dll will allow you to identify specific instances of dllhost that are executing ASP script code. COM programs executing inside the mtx.exe container process and COM+ programs executing inside the dllhost.exe container process can be identified, too, if you build a filter list of component application DLLs. To populate the Module filter list, use the “Browse for Modules” function to point to a folder where these component application DLLs reside in your installation. You should wind up up with something that looks like the Module Filter definition in Figure 2:

Figure 2.
The effect of this filter is to report a Module instance associated with each process instance of dllhost.exe where the COM+ components dasserver.dll or gam.dll are loaded.

To populate the Module filter list that is illustrated in Figure 2 for either dllhost.exe or mtx.exe, use the “Browse for Modules” function to point to a folder where these component application DLLs reside in your installation. If necessary, use the Component Services Explorer (CSE) applet, illustrated in Figure 3, to locate the names of the COM+ modules that want to resolve. (CSE is available under Administrative Tools.)

Figure 3.
Using CSE, drill down to Component Services, My Computer,  and determine what COM+ Server applications are installed. COM+ Server applications are identified by an icon that shows the component residing inside a box, which represents the dllhost.exe (or mtx.exe) container process (e.g., IIS Out-of-Process Pooled Applications). The icon for COM+ Library applications shows the component being loaded into the calling process (e.g., IIS In-Process Applications).  If you are not sure if the COM+ component is a Library or Service application, right-click to access the Component Properties and check the Activation tab, as illustrated in Figure 4.

Figure 4.
Only COM+ Server applications that are activated in a dedicated local server container process (dllhost.exe or mtx.exe), as shown, need Module name resolution.

Finally, find out the COM+ component module name so that you can prepared the Module Filter definition. Drill down to the COM+ Components and right-click to access Component properties. Under the General tab, illustrated in Figure 5, the fully qualified DLL module name is shown. Enter the Module name shown, without any elements of the path, in the dllhost.exe or mtx.exe Filter definition.

Figure 5.
In this example, the GAM.dll, a COM+ component associated with the Microsoft sample FMStocks application, is defined as a Server application. When the FMStocks application calls this component, it executes inside an instance of dllhost.exe. When the NTSMF collection services finds an instance of dllhost.exe with gam.dll running inside it (the module name is not case-sensitive), it generates a Module Object instance associated with gam.dll, that shows a parent instance of dllhost.exe. Since there are likely to be multiple copies of dllhost.exe executing, the Module instance record contains an ID Process Counter that identifies the unique instance of the dllhost container process where the Module is loaded and executing. In reporting on COM+ components, we suggest you Merge the Module name with its associated Process records, based on ID Process, and report the Module name, rather than the uninformative name of the dllhost container process.

The Module data is for identification purposes. The only Counters available for each Module are the process ID, which is used to identify the parent process uniquely, and the Load Address of the Module within the parent process virtual address space.

The Module data is intended to assist in identifying the application being executed within a container process, which is something we notice occurring more and more frequently in Windows Server. There are three specific container processes that you are likely to collect Module Object information about: mtx.exe in Windows NT 4.0, dllhost.exe and svchost.exe in Windows Server and XP. The function of these container processes is described below:

mtx.exe is a container processes used by the Microsoft Transaction Server (mts) to execute COM components (which are DLLs). When COM program DLLs are loaded as server components and execute out-of-process, the component is executed inside the mtx.exe container process.

dllhost.exe is the Windows Server version of mtx.exe that executes COM+ components. When COM+ program DLLs are loaded as server components and execute out-of-process, the component is executed inside the dllhost.exe container process. dllhost.exe is also used to execute Active Server Pages application scripts in IIS in separate container processes, when Medium or High Application Protection is specified. Medium Application Protection, a runtime option introduced with IIS and is the default setting, leads to all ASP script running inside a single copy of dllhost.exe. When a High level of Application Protection is chosen, each ASP script executes in an isolated instance of dllhost.exe. ASP scripts can be identified inside dllhost.exe by looking for the presence of wam.dll.
svchost.exe is used in Windows XP to host system services like Browser, Redirector, and Server. In Windows XP, those system services that used to execute within the services.exe container process in earlier versions of Windows NT, are arrayed across multiple instances of the svchost process, each executing under a different security profile, either SYSTEM, LOCAL SERVICE, or NETWORK SERVICE.

If you are experiencing application-related performance problems and notice lots of mtx.exe or dllhost.exe processes executing, use the Module function to identify which applications were running inside which container processes. During reporting Merge the Module instance with the parent process, using the ID Process field to uniquely identify specific processes, and replace the generic process name with the Module instance name.

N = l * S_r

where N is the number of outstanding requests in the system, l is the arrival rate of requests, and S_r is the response time. So the Ave Disk Queue Length Counter is an estimate of the number of outstanding request to the (Logical or Physical) disk. This includes any requests that are currently in service at the device, plus any that requests that are waiting for service. If requests are currently waiting for the device inside the SCSI device driver layer of software below the diskperf filter driver, the Current Disk Queue Length Counter will have a value greater than 0. If requests are queued in the hardware, which is usual for SCSI disks and RAID controllers, the Current Disk Queue Length Counter will show a value of 0, even though requests are queued.

Since the Ave Disk Queue Length Counter value is a derived value, not a direct measurement, you do need to be careful how you interpret it. Little’s Law is a very general result that is often used in the field of computer measurement to derive a third result when the other two values are measured directly. However, Little’s Law does require an equilibrium assumption in order for it be valid. The equilibrium assumption is that the arrival rate equals the completion rate over the measurement interval. Otherwise, the calculation is meaningless. In practice, this means you should ignore the Ave Disk Queue Length Counter value for any interval where the Current Disk Queue Length Counter is not equal to the value of Current Disk Queue Length for the previous measurement interval.

Suppose, for example, the Ave Disk Queue Length Counter reads 10.3, and the Current Disk Queue Length Counter shows 4 requests in the disk queue at the end of the measurement interval. If the previous value of Current Disk Queue Length was 0, the equilibrium assumption necessary for Little’s Law does not hold. Since the number of arrivals is evidently greater than the number of completions during the interval, there is no valid interpretation for the value in the Ave Disk Queue Length Counter, and you should ignore the Counter value. However, if both the present measurement of the Current Disk Queue Length Counter and the previous value are equal, then it is safe to interpret the Ave Disk Queue Length Counter as the average number of outstanding I/O requests to the disk over the interval, including both requests currently in service and requests queued for service.

You also need to understand the ramifications of having a total disk round trip time measurement instead of a simple disk service time measure. Assuming M/M/1, a disk at 50% busy has one request waiting on average and disk response time is 2 * service time. This means that at 50% busy – assuming M/M/1 holds, an Ave Disk Queue Length value of 1.00 is expected. That means that any disk with an Ave Disk Queue Length value greater than 0.70 probably has a substantial amount of queue time associated with it. The exception of course is when M/M/1 does not hold, such as during a backup operation when there is only a single user of the disk. A single user of the disk can drive a disk to near 100% utilization without a queue!

To help you get started, we produced an annotated list of some of the more useful Performance Counters, which also documents some of the common gotchas that you can read more about online in this FAQs section.

The Default Data Collection set (DCS) is enabled at the factory and runs until you assign your own DCS. This is a good, general purpose set of metrics to collect and is consistent with the built-in chart templates that are included with Performance Sentry Portal.

If you want to get involved at a deeper level with the interpretation and analysis of Performance Sentry performance data, we recommend that you pick up a copy of the Microsoft Server 2003 Resource Kit. The Resource Kit contains a volume written by Mark Friedman on server performance and tuning. Mark is the founder of Demand Technology, and he worked with Microsoft technical staff to create this volume, drawing from his extensive experience using the Performance Sentry data to analyze the performance of Windows machines.