A number of tools are available to help you test and monitor the performance of your Web application. ASP.NET includes 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.
Some visual designers include tools for testing ASP.NET applications. For example, Microsoft Visual Studio 2005 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. For more information, refer to the ACT documentation on the
Most ASP.NET performance counters are exposed for individual applications. In the Windows Performance Monitor (Perfmon.exe), the per-application counters are available under the ASP.NET Applications performance object. If there are multiple applications on the server, you specify a particular application instance when selecting a counter to monitor. In addition, there is a special __Total__ application instance in Performance Monitor that aggregates the counter values for all applications on a server.
ASP.NET also exposes global counters that are not bound to a particular application instance. These counters are located under the ASP.NET performance object. For instructions on how to view these counters in Windows Performance Monitor, see How to: View the ASP.NET Performance Counters Available on Your Computer. For information about each of the ASP.NET system and ASP.NET application performance counters, see Performance 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 rendered size of controls on your page. For more information about tracing, see ASP.NET Tracing.
Because ASP.NET runs under 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, using the profiling services of the common language runtime. For more information about profilers, see .
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, if the application has not been precompiled, there can be the cost of compiling an instance of the class. Once the application is compiled, performance will improve for subsequent requests.
For more information about performance monitoring in the .NET Framework, see .