Profiling Managed Code

Profiling Managed Code

In this next section we ll be discussing how to instrument and profile your managed (and your unmanaged) code using Compuware s DevPartner Studio 7.0. There are many good profilers available on the market, but we are using DevPartner Studio as an example because it is the profiler of choice used by the ACE Team at Microsoft.

Using Compuware DevPartner Studio

Compuware Corporation s DevPartner Studio Professional Edition can assist you in creating reliable, high-performance applications. The performance analysis component makes it easy to pinpoint performance bottlenecks anywhere in your code, third party components, or operating system, even when source code is not available. An evaluation version of DevPartner Studio 7.0 Professional Edition can be obtained at http://www.compuware.com/products/devpartner/.

Profiling with DevPartner Studio

In many applications, a relatively small portion of the code is responsible for much of the application s performance. The challenge is to quickly identify which parts of the code are the most likely candidates for changes that can improve performance, so developers can focus their limited time on tuning efforts that have a high probability of improving overall performance.

The performance analysis capability in DevPartner Studio measures the frequency of execution and execution time down to the line of code for a wide variety of components: Visual Basic, Visual C++, Visual Basic .NET, C#, Visual C, native C/C++, as well as Web applications using ASP.NET, JScript and VBScript when using IE or IIS.

Collecting performance data is straightforward with DevPartner Studio. For managed code, simply run your application with Performance Analysis enabled. For unmanaged code, enable the Instrumentation Manager and rebuild. While you are exercising your application, you can optionally use the session controls (start, stop, and clear) to focus your data collection on areas of specific interest.

One possible methodology is to collect performance data at the method level only (rather than the line level), avoiding the instrumentation step for the moment, assessing which methods are most expensive, and then running line-level data collection on the methods of most interest. This technique points you very quickly in the direction of which subset of methods are the most likely candidates for improvement.

NOTE
To avoid collecting data for all system (nonsource) files, check Exclude System Images on the DevPartner Performance and Coverage Exclude Images options page. Once you optimize your source code, turn off this option so you can examine how your application uses system code, especially if you are using the .NET Framework.

Profiling Session Window

Once you are done executing your application, performance data is displayed in a Session window, as shown in Figure 7-1. The filter pane on the left lists the source files and system images used during the session, along with the percentage of time spent in each file during execution. You can quickly browse to any file and view the methods contained within that file. In this example, note that we have an application with a mixture of native C++ and C# code. You can also select useful collections of files or methods (such as the Top 20 methods) in order to focus attention on which code is using the most execution time or is called most frequently. The Session data pane on the right provides the detailed method list and associated source code, along with overall summary information.

Figure 7-1. DevPartner Studio Performance Analysis Session Window

One way to proceed is to sort the session data by the average time spent in each method, and then to begin to examine the most expensive methods for possible improvements. By selecting a method in the Session data pane, you can examine the source code in more detail. Figure 7-2 provides example source code, which is annotated with the number of times each line of code has executed, the percentage of time spent in called (children) functions, and the total time spent executing the line of code. The most expensive line is also highlighted, which could be your starting point for candidate code to further tune.

Figure 7-2. DevPartner Studio Performance Analysis Source Code Window

Profiling Method Details

Another approach to improving performance is to explore the relationships between the functions called in your application. By selecting a method, the details of that method including what other methods it calls and what methods call it are displayed as shown in Figure 7-3. The top section of the display identifies the selected method and contains performance data for the method. The Parents section lists all methods that called the selected method, and the Children section lists all methods called by the selected method. Using the Method Details view allows you to quickly understand the method calling relationships and costs, traverse the calling sequence to help you better understand both how your own code is working, and understand the impact of calls to the supporting infrastructure.

Figure 7-3. DevPartner Studio Performance Analysis Method Details Window

Working with Distributed Applications

DevPartner Studio provides performance data gathering and reporting capabilities for the distributed application environment, including Web-based applications. It provides end-to-end profiling for distributed, component-based applications. For distributed Web-based applications, DevPartner collects data for Web applications created in Visual Studio .NET, as well as applications that use the scripting languages supported by IE and IIS.

When you run a distributed application, DevPartner can collect data for each separate local or remote process, including server session data, and correlate the session data. Data correlation combines session data from multiple processes into a single session file that you can view to analyze results for the entire application. DevPartner automatically correlates the session data between different processes when there are

• DCOM-based calls between methods in different processes

• HTTP requests between IE as client and IIS as server

To preserve the relationship between the methods of DCOM objects or the relationship between HTTP client and server (IE and IIS), DevPartner automatically correlates the data from those sessions. It then combines the correlated data with the client session data into a single session file. You can view the session file with the correlated data and navigate between calling and called methods in the Method Details view. You can use the Correlate Performance Files command by choosing DevPartner from the Tools menu to manually combine data from different session files when there is no COM-based relationship or client/server relationship between IE and IIS.

Effective Performance Analysis for .NET

The .NET Framework is particularly rich and complex, and you can accomplish a lot with a few lines of code. This offers great opportunities to developers, but can make it difficult to tune application performance. For example, you may discover that 95 percent of your application s execution time is spent in the .NET Framework. How do you improve performance in that case? Here are some basics to make the performance analysis process using DevPartner Studio more productive.

Understand What You Want to Measure

Consider how your application behaves before you begin collecting performance data. For example, if you are profiling a Web services or ASP.NET application, think about how Web caching will affect your results. If your test run inputs the same data repeatedly, your application will fetch pages from the cache, skewing the performance data. In such a case, you could take pains to ensure variable input data, or more simply, edit the machine.config file to turn off caching while you test. Comment out the line that reads:

<add name="OutputCache" type="System.Web.Caching.OutputCacheModule"/> 

Understand Start-up Costs

The .NET Framework performs many one-time initializations. To prevent these from skewing performance results, warm up the application by exercising all the features you want to profile, and then clear the data using the Clear button on the Session Control toolbar. Next, run a test that exercises the same features to get a more accurate performance picture.

Understand .NET Framework Costs

Use % with Children on the Method List or Source tab to see how much time you are spending in the .NET Framework. Use the Child Methods window in Method Details to drill into the .NET Framework to understand which calls are expensive and why. Rework the application to do less work or to call the .NET Framework less often.

Collect Complete Data for Distributed Applications

When you analyze performance for a Web application, a multi-tier client/server application, or an application that uses Web services, include all remote application components in the analysis. Use DevPartner Performance and Coverage Remote Agent to configure performance data collection on remote systems. If your application uses native C/C++ components, instrument the components for performance analysis before collecting data. Of course, the recommendations regarding awareness of application behavior, start-up costs, and .NET Framework costs apply equally to collecting data for server-side components.

Using AppMetrics to Monitor .NET Enterprise Services Components

COM+ provides COM (unmanaged code) components with services to let applications easily achieve higher scalability and throughput. For .NET Framework (managed code) components, these same services are also available through Enterprise Services. These services include transaction coordination across distributed resources, object pooling, role-based security, etc. You can set up your managed and unmanaged code components to use these services.

AppMetrics for Transactions (AppMetrics) is a monitoring system for Enterprise Services applications that we use internally to profile the performance of heavily used COM+ components. Many of the application groups we deal with find themselves having to wrap their managed code in COM+ components in order to communicate with legacy systems. Capturing performance data produced by AppMetrics enables us to easily determine whether or not the COM+ application may be the cause of poor application performance.

You can use AppMetrics to monitor managed and unmanaged Enterprise Services components. It is designed to monitor applications running in either pre-production or production environments. AppMetrics monitors applications without any code instrumentation.

AppMetrics Manager and Agent Monitors

To reduce the effects of monitoring on system and application performance, AppMetrics uses a Manager and Agent setup. In this arrangement, AppMetrics runs its Agent on the application server. The Agent collects data about the Enterprise Services components while using a minimal amount of system resources. This lets AppMetrics capture more precise data about the applications, whether they run under simulated or real load.

The Agent sends its data to a Manager, which resides on a separate machine. Based on this data, the Manager generates metrics about the applications and their components. These metrics include the total number of activations for component instances, the rates at which the instances finish, and the actual durations of individual instances. You can use these metrics to find any bottlenecks that may occur in your applications during runtime.

The Manager machine stores the metrics in a database. From here, you can generate reports about the application processes and their component instances.

Setting Up AppMetrics Manager and Agent

To evaluate your managed and unmanaged code components while they run under Enterprise Services, set up AppMetrics within your application system with the following tasks:

1. On the AppMetrics Manager machine, add a Manager monitor.

2. Add an Agent monitor to the Manager monitor. In effect, this creates the Agent monitor on the application server.

3. Select the application(s) to be monitored on the application server.

   

   Figure 7-4. Diagnostics Application Configuration Panel

4. Within the selected applications, you can set up specific components for monitoring.

Pre-Production Monitoring in AppMetrics

For pre-production monitoring, AppMetrics offers a type of analysis that it calls the Diagnostics Monitor. The Diagnostics Monitor records details about individual component and transaction activity in a running application.

The Diagnostics Monitor displays the metrics in a drill-down report. This report shows durations for each active component in the application. It also shows the logical chain of method calls between the components. This is important because merely viewing the metrics for each component in isolation from other components does not tell the whole story. It says nothing about how a component may make calls to other components.

With the information about the method call chains between components in the drill-down report, you can begin to see the relationships between components during runtime. It lets you analyze the overall response time of a component based on its constituent parts.

From this analysis, you can determine if the bottleneck occurs either in the root component object or somewhere further down the method call chain in a subordinate component.

Figure 7-5 shows a snippet from an AppMetrics for Transactions report, which illustrates the following:

• The logical chain of method activity.

• An FMStock7.DAL.Broker component that invokes a subordinate FMStocks7.GAM.7 component instance.

• The CreditAccountBalance method, which was invoked on the subordinate component.

• The unique naming convention for cross-application calls. When the code makes such calls, they are preceded with the other application name plus a colon. In this case, the FMStocks7.GAM.7 component resides in a different application from the FMStocks7.DAL.Broker component.

Figure 7-5. Diagnostics drill-down report

NOTE
In addition to the information shown here, the Diagnostics drill-down report also provides actual start times, end times, and error codes for each item.

With the information about cross-application calls in these reports, you can evaluate whether the subordinate component deserves to be in the other application. Cross-application calls can be expensive in terms of CPU utilization. They can also prolong the duration of the method call itself.

If one component makes several cross-application calls during a single transaction into a subordinate component, it may be advisable to make the subordinate component run in the same application process with the first component. You can accomplish this in several ways. For example, you can move the subordinate component into the same application with the first component. Alternatively, you can move the subordinate component into a library application.

Additional Diagnostics Information

Before an application goes to production, you will want to know its limitations. Figure 7-6 shows a snippet from an AppMetrics report that details method activity on the FMStocks7.GAM.7 component instances during a 10-minute period of intense load.

Observe that the average duration for the monitored methods is quite long and not all method calls succeeded during the period.

Figure 7-6. Diagnostics report on methods

Observing the performance of a component over time can be quite revealing. Figure 7-7 shows a snippet from an AppMetrics for Transactions report, which illustrates component activity over a four-hour period of intense load.

Figure 7-7. Diagnostics report on components

Production Monitoring

To monitor Enterprise Services applications running in full production environments, AppMetrics offers the Production Monitor. This monitor generates metrics about the activity in Enterprise Services applications on an interval basis, but with lower overhead and information granularity than is available in the Diagnostics Monitor. More specifically, the Production Monitor calculates totals and rates of activity about components and their instances, as shown in Figures 7-8, 7-9, and 7-10.

Figure 7-8. Active components chart

Figure 7-9. Component rate chart

Figure 7-10. Component duration chart

The Production Monitor can also generate application-process metrics, such as application starts, stops, and crashes. The AppMetrics runtime UI shows process metrics for each Enterprise Services application process. The following example shows resource utilization by the process corresponding to FMStocks7.GAM.

Figure 7-11. Application Process Runtime view

The Production Monitor also offers proactive monitoring through alerts. This means that you can set up thresholds of activity for a specific component metric, such as its average duration. If AppMetrics detects activity above these levels in your system, it can send alerts by email or SNMP. AppMetrics can also respond to alert conditions by invoking a custom COM component, where you can program an automated response to the condition.

The AppMetrics runtime UI shows metrics for each monitored Enterprise Services component. Figure 7-12 shows that the FMStocks7.DAL.Broker component instances are taking an average of over ten-seconds from creation to completion. Since such numbers fall outside the specified thresholds, an alert will be triggered.

Figure 7-12. Application Process Runtime view