ASP.NET Performance Overview
Creating Web applications that respond to user requests quickly, even when a large number of requests are being processed on the server, has been a challenge for developers and IT personnel since the Internet began. Monitoring Web site performance is something that all Internet and intranet developers need to be able to do. ASP.NET was designed with this in mind.
The ASP.NET model provides a number of built-in performance enhancements that are not included in earlier versions of ASP. Particularly, there are two enhancements involved in processing HTTP requests. First, when an ASP.NET page is requested for the first time, an instance of the Page class is dynamically compiled. (In earlier versions of ASP, page code was interpreted for requests in the order that they appeared on the page.) The common language runtime just-in-time (JIT) compiles ASP.NET managed page code to the native code of the processing server at run time. Second, when the Page instance has been compiled for the first request, it is cached on the server. For each subsequent request for that page, the cached instance of the class is executed. After the initial request, the Page class is recompiled only when the original source for the page or one of its dependencies has changed.
In addition, ASP.NET caches internal objects, such as server variables, to speed user code access. As a part of the .NET Framework, ASP.NET benefits from the performance enhancements provided by the common language runtime, including the previously mentioned JIT compiling, a fine-tuned common language runtime for both single and multiprocessor computers, and so on.
These enhancements, unfortunately, cannot protect you from writing code that does not perform well when a large number of HTTP requests are processed by your application simultaneously. You must test your application to ensure that it meets the demands of its users. There are four common performance measures that you can test to ensure that your application is performing well.
- Execution Time
The time it takes to process a request, usually measured between the first byte and the last byte returned to the client from the server. Execution time directly affects the throughput calculation. - Response Time
The length of time between when a request is requested and when the first byte is returned to the client from the server. This is often the most perceptible aspect of performance to the client user. If an application takes a long time to respond, the user can become impatient and go to another site. The response time of an application can vary independently of (even inversely to) the rate of throughput. - Scalability
The measurement of an application's ability to perform better as more resources (memory, processors, or computers) are allocated to it. Often, it is a measurement of the rate of change of throughput with respect to the number of processors. - Throughput
The number of requests a Web application can serve per unit of time, often measured in requests per second. Throughput can vary, depending on the load (number of client threads) applied to the server. This is usually considered the most important performance metric to optimize.
To write applications that perform well, it is important to maintain a balance of these metrics. No single measurement can characterize how your application will behave under varying circumstances, but several measurements taken together can show how well your application is performing. For more information about taking measurements of this kind, as well as information about the performance counters provided with ASP.NET, see Monitoring ASP.NET Application Performance.
For suggestions on how to create high-performance applications, see Developing High-Performance ASP.NET Applications.