The question you might be asking now is, "How do I make heads or tails of the event data?" Unfortunately, Microsoft hasn't documented the data that AD and related providers supply. Fortunately, all event-tracing providers are registered in the WMI namespace. Thus, you can use tools such as WMI CIM Studio to find out each provider's transactions and the data fields in those transactions. WMI CIM Studio is available for download from the Microsoft Download Center (http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=6430f853-1120-48db-8cc5-f2abdc3ed314). You can find the registered providers in the root\WMI\EventTrace path.
Figure 4, page 36, shows the information that WMI CIM Studio provides for the GetASTicket transaction. As you can see, WMI CIM Studio refers to the transactions as classes and the data fields as properties. Although WMI's property names don't exactly match the heads for the data fields in the .csv file, the property names are similar enough to let you determine the data fields in the .csv file.
If you don't want to work with the raw data in the .csv file, you can use the workload report. Figure 5 shows the workload report that tracerpt.exe generated from the AD logon trace. To provide this report, tracerpt.exe transformed the .csv file's raw data into meaningful statistics, such as the total number of transactions. To calculate the total number of GetASTicket transactions, for example, tracerpt.exe paired up GetASTicket's Start and End Type events in the .csv raw data. Then, tracerpt.exe counted the number of pairs.
Another statistic in the workload report is Response Time(ms), which represents the total time spent in a transaction. A response time of 0 means that the report wasn't formatted to show the number of decimal places required to present a value that's quite small (e.g., 0.00023). Hence, tracerpt.exe rounds the number up to 0.
The workload report in Figure 5 shows that 14 different types of transactions occurred during a user logon. Each of those transactions takes some time to execute and takes up CPU time. In addition, some transactions execute more than once. The .csv file tells you how long each transaction takes between start and end and how many clock ticks each transaction takes. Thus, by using the information in both reports, you can total CPU times to determine the CPU load on the DC for one user logon session. For example, if you import the .csv file into Excel, you can sort by transaction name and add up the kernel and user CPU times for each start-end pair to obtain the total CPU time for each transaction type. This result would provide more granularity than the statistic in the workload report.
Keep in mind that you're looking only at AD and its related subsystems, such as Kerberos and the LSA process. This trace doesn't capture other logon-related events, such as downloading a user profile or grabbing Group Policy information. If necessary, you can use some of the other providers to capture data on these events. For example, you can use the Windows Kernel provider to capture file I/O metrics.
Also keep in mind that you shouldn't simply multiply the load generated by one user logging on to the DC by the number of users to determine overall load. Load is typically nonlinear because AD and other transactions benefit from such processes as memory caching. So, to get a true view of load as you scale up users, repeat the load-tracing test with an incremental increase in users to determine how number of users relates to overall CPU load.
The Power of Event Tracing
Event tracing provides many opportunities to get detailed information about what's happening on your Windows system, where time is being spent, and how many resources are being consumed for a given operation. Using the ETW facility in test and production environments can give you insight about the performance of your systems and applications—a level of insight that Performance Monitor just can't touch.
Register
John January 05, 2004