Analyzing Performance and Diagnosing Issues
Profiling a .NET web service frequently requires looking at both managed and unmanaged code simultaneously because all but the most trivial calls into native code must undergo a mode transition. The mode transition, which is the physical process of moving data between the managed and unmanaged modes of operation, typically requires about two dozen instructions. The second cost is marshalling the data to move across the boundary. Marshalling is computationally expensive, and the more data you move back and forth, the more expensive it becomes. Tests have indicated that marshalling complex data can involve up to several thousand instructions.
Alternatively, within the Microsoft model, web services can also be unmanaged. Existing or new COM components can be used to implement the business facade, business logic and data access layers. Using Windows Server 2003, developers and system administrators can allow existing COM+ applications to be called using XML/SOAP by simply checking a configuration box. COM components also can be used as a part of a managed .NET web service.
Therefore, you may be making unmanaged calls from your .NET web service, whether you are using it as a gateway to call COM objects, making platform calls or using prepackaged native components. Profiling both managed and unmanaged calls together gives you a comprehensive view of the web service, and most important, a view of the performance cost of mode transitions. You should also look at the number of times you're crossing the managed/unmanaged boundary. Because this process is so computationally expensive, you should seek to reduce the number of times it occurs (see Figure 2). The granularity of your profiling should be at least to the method level, and preferably to the individual line of code. At the method level, you can quickly get a view of what operations your code spends most of its time performing.
In addition to obtaining the execution time and number of calls, you should also be able to analyze your code in several different views of performance, including percent of time in both method and children. Walking the call stack is an excellent way of determining what resources, .NET services and OS services your web service uses, and how expensive those services are (see Figure 3).
