Monitoring ASP.NET Application Performance

  • [アーティクル]

There are a number of tools available to help you test and monitor the performance of your Web application. Microsoft Visual Studio .NET provides Application Center Test 1.0 (ACT), which simulates a large group of users by opening multiple connections to a Web server and rapidly sending HTTP requests. ASP.NET includes a number of performance counters that you can use to track the execution of your application. You can also use the built-in ASP.NET tracing feature to track code execution for a page or an application.

ACT is designed to stress test Web servers and to analyze performance and scalability problems with Web applications. For more information about ACT, either install Visual Studio .NET and open the ACT documentation, or perform a search on MSDN at https://msdn.microsoft.com.

Unlike traditional Active Server Pages (ASP), which exposed performance counters globally for the entire server computer, most of the ASP.NET performance counters are exposed per application. In the System Monitor tool (PerfMon), the per-application counters are available under the ASP.NET Applications performance object. If there are multiple applications on the server, you need to select a particular application instance when selecting a counter to monitor. However, there is a special __Total__ application instance in PerfMon that aggregates the counter values for all applications on a server. __Total__ is usually a sum of the counter values.

ASP.NET also exposes global-only counters that are not bound to a particular application instance. These counters are located under the ASP.NET performance object. To view the total available counters for ASP.NET on a Windows 2000 Server computer, use the following steps.

To view the available ASP.NET counters on a Windows 2000 Server computer

  1. From the Start button, point to Programs, point to Administrative Tools, and then click Performance.
  2. In PerfMon click View Report.
  3. Click Add.
  4. Select ASP.NET Applications, select All counters, then click OK.
  5. Select ASP.NET System, select All counters, then click OK.

To view the available ASP.NET counters on a Windows XP computer with IIS installed

  1. From the Start button, click Run.
  2. Enter perfmon in the Open text box and then click OK.
  3. In PerfMon click View Report.
  4. Click Add.
  5. Select ASP.NET Applications, select All counters, then click OK.
  6. Select ASP.NET System, select All counters, then click OK.

For information about each of the ASP.NET system and ASP.NET application performance counters, seePerformance Counters for ASP.NET.

ASP.NET also includes a trace feature that can show you important timing information between successive trace output statements, as well as information about the server control hierarchy, the amount of view state used, and the render size of controls on your page. For more information about tracing, see ASP.NET Trace.

Because ASP.NET is running on top of the common language runtime, it is possible to profile a Web page completely, from its entry point through any middle tier objects and to its end. This kind of profiling was not possible in ASP and provides a great tool for performance work in ASP.NET. Moreover, all common language runtime profilers are able to profile ASP.NET pages. Given the profiling services of the common language runtime, there is no need to instrument one's code beforehand; it is done at run time. For more information about profilers, see Debugging and Profiling Applications.

There are two major types of profilers: call-attributed profilers and sampling profilers. Call–attributed profilers allow you to view all method calls for a page or application and can give specific timings for each method call and any child method call it may contain. This is the most useful type of profiling for analyzing code paths and trying to trim them. However, if execution runs through any code path that has not been instrumented (for example when COM or native methods are called from ASP.NET), the profiler cannot keep track of when the methods were called. In such a case, the profiler attributes them to the last method that contains instrumentation code. For more information on including instrumentation in your code, see Debugging and Profiling Applications.

A sampling profiler is different in that no instrumentation needs to be done beforehand. Such a profiler essentially samples the CPU either at specified intervals or upon CPU interrupts and keeps track of what code is executing. It can then provide the user with a view of what code was most often executing during that period of time. This type of profiling is most useful for troubleshooting lock/resource contentions and performance bottlenecks in the code.

When you are doing steady-state running analysis, it is often best to ignore the first request and any one-time initialization costs for objects. For example, when requesting an ASP.NET page for the first time, there is always the cost of compiling an instance of the Page class. Once that has occurred, performance will improve for subsequent requests.

For more information about performance monitoring in the .NET Framework, see Monitoring Performance Thresholds.

See Also

ASP.NET Optimization | Monitoring Performance Thresholds | Performance Counters for ASP.NET