The Event Tracing for Windows (ETW) subsystem is a powerful tool for your performance-testing and diagnostics arsenal. Microsoft created ETW to give developers a mechanism with which to determine their applications' performance effects on Windows Server 2003, Windows XP, and Windows 2000 platforms. However, administrators can use ETW to find out what's happening in their internal Windows systems, Microsoft applications (e.g., Microsoft IIS), and third-party applications and troubleshoot any problems they might find. ETW can also help administrators with capacity planning by letting them monitor a system under real workloads to see how it performs for a given set of transactions. Before I show you the ETW tools, techniques, and an example of real-world usage, let's look at the ETW architecture.
The ETW Architecture
You might be asking why Microsoft would develop yet another way to obtain performance data when you already have the Performance Monitor tool. The answer is that Microsoft wanted to provide a low-overhead facility for application developers and administrators to monitor applications and processes in production environments without causing the system to slow to a crawl. Running Performance Monitor against production servers 24 x 7 and not expecting it to significantly affect the performance of those servers isn't realistic. However, Microsoft designed ETW to do just that. ETW accomplishes this feat by using an architecture that combines both kernel-mode and user-mode components optimized to quickly write events to a log or consumer application.
As Figure 1 shows, the ETW architecture consists of several components: an event tracer, a log or consumer application, providers, and a controller application. The event tracer creates kernel-mode or user-mode logging sessions that perform the actual trace. Windows 2003 and XP can support as many as 62 logging sessions, whereas Win2K supports as many as 31 sessions. Each session has a dedicated pool of buffers to which the event tracer writes event data. Windows creates buffers on a per-processor basis, so if an application raises an event on processor 0, the event tracer writes the event to that processor's trace buffer. You can specify the minimum and maximum number of buffers that Windows should create for a given logging session. By default, Windows creates the buffers in the nonpaged pool memory area of the system, which means that Windows won't page the event data in the buffers to disk if the system is under memory pressure. This default is a performance advantage for the logging session because the buffers will always be in memory when they're needed. However, when you set up the logging session, you can specify that the buffers use paged-pool memory instead.
The event tracer puts a timestamp on each event. The timestamp contains the following information:
- time of the event
- process ID under which the event occurs
- thread ID under which the event occurs
- user-mode CPU time
- kernel-mode CPU time
When you set up a tracing session, you can specify the timestamp's resolution. You can specify from 100 millisecond (ms) resolution to 100 nanosecond resolution, depending on the mechanism the event tracer uses to get the timestamp. The lower the resolution, the less the impact on overall system performance during a tracing session. However, you'll see less resolution in your logged data.