The article contains guidelines for improving your ASP.NET Web applications
Introduction
ASP.NET has been developed with lots of features which makes developer life easy. Start from ViewState, PostBack, Server Controls , User Controls and etc. All of them can make your web development experience fun and easy, but improper use of them can cause your site performance slowdown. Most of the controls generate overhead to the client and server. Therefore in this article, I I will list out about things you can do and don't to improve your ASP.NET website performance.
Tips for Improving ASP.NET Performance
1.Avoid unnecessary round trips to the server
There are circumstances in which using ASP.NET server controls and performing postback event handling are unnecessary. For example, validating user input in ASP.NET Web pages can often take place on the client before that data is submitted to the server. You can write your own simple javascript on client side to validate the control rather than have to do full page postback just to validate the control. If you are using .NET validation control, you can set the EnableClientScript to true, so that it will not do a postback for every control validation.
2. Use the Page object's IsPostBack property to avoid performing unnecessary processing on a round trip
If you write code that handles server control postback processing, you will sometimes want code to execute only the first time the page is requested rather than on each postback. Use the Page.IsPostBack property to check if the postback event is true or not. By doing this, you can prevent for double binding for your server control.
3. Enabled ViewState only if needed.
ASP.NET server controls and user controls comes with ViewState Enabled by default. Although ViewState can help you to remember the control values during the postback event without have to write any code, they can also introduce overhead to the client because of the additional data needed to be passed to client browser. You can set this to off, especially for the control that you bind the data for every round trip.
4.Leave buffering on unless you have a specific reason to turn it off
There is a significant performance cost for disabling buffering on your ASP.NET Web pages.
5. Use the Server.Transfer method from the Server object or cross-page posting to redirect between ASP.NET pages in the same application
Tips for Improving ASP.NET Performance
1.Avoid unnecessary round trips to the server
There are circumstances in which using ASP.NET server controls and performing postback event handling are unnecessary. For example, validating user input in ASP.NET Web pages can often take place on the client before that data is submitted to the server. You can write your own simple javascript on client side to validate the control rather than have to do full page postback just to validate the control. If you are using .NET validation control, you can set the EnableClientScript to true, so that it will not do a postback for every control validation.
2. Use the Page object's IsPostBack property to avoid performing unnecessary processing on a round trip
If you write code that handles server control postback processing, you will sometimes want code to execute only the first time the page is requested rather than on each postback. Use the Page.IsPostBack property to check if the postback event is true or not. By doing this, you can prevent for double binding for your server control.
3. Enabled ViewState only if needed.
ASP.NET server controls and user controls comes with ViewState Enabled by default. Although ViewState can help you to remember the control values during the postback event without have to write any code, they can also introduce overhead to the client because of the additional data needed to be passed to client browser. You can set this to off, especially for the control that you bind the data for every round trip.
4.Leave buffering on unless you have a specific reason to turn it off
There is a significant performance cost for disabling buffering on your ASP.NET Web pages.
5. Use the Server.Transfer method from the Server object or cross-page posting to redirect between ASP.NET pages in the same application
6.Disable session state when you are not using it
Not all applications or pages require per-user session state; you should disable session state if it is not needed. To disable session state for a page, set the EnableSessionState attribute the the Page Directive to false.
<%@ Page EnableSessionState=false%>
7.Choose the appropriate session-state provider for your application needs
ASP.NET provides multiple ways to store session data for your application: in-process session state, out-of-process session state as a Windows service, and out-of-process session state in a SQL Server database. Each has its advantages, but in-process session state is by far the fastest solution. If you are storing only small amounts of volatile data in session state, it is recommended that you use the in-process provider. Out-of-process session state options are useful if you scale your application across multiple processors or multiple computers, or where you would like to retain session data if a server or process is restarted
8.Use SQL Server and stored procedures for data access
Of all the data access methods provided by the .NET Framework, using SQL Server for data access is the recommended choice for building high-performance, scalable Web applications. When using the managed SQL Server provider, you can get an additional performance boost by using compiled stored procedures wherever possible instead of SQL commands. For information about using SQL Server stored procedures
9.Use the SqlDataReader class for a fast forward-only data cursor
The SqlDataReader class provides a forward-only data stream retrieved from a SQL Server database. If you can use a read-only stream in your ASP.NET application, the SqlDataReader class offers higher performance than the DataSet class.
10.Cache data and page output whenever possible
ASP.NET provides mechanisms for caching page output or data when they do not need to be computed dynamically for every page request. In addition, designing pages and data requests to be cached, particularly in areas of your site where you expect heavy traffic, can optimize the performance of those pages. Using the cache appropriately can improve the performance of your site more than using any other feature of the .NET Framework.
When using ASP.NET caching, note the following. First, do not cache too many items. There is a memory cost for caching each item. Items that are easily recalculated or rarely used should not be cached. Second, do not assign cached items a short expiration time. Items that expire quickly cause unnecessary turnover in the cache and can cause extra work for cleanup code and for the garbage collector. You can monitor the turnover in the cache due to items expiring by using the Cache Total Turnover Rate performance counter associated with the ASP.NET Applications performance object. A high turnover rate can indicate a problem, especially when items are removed before they expire. (This situation is sometimes known as memory pressure.)
11.Avoid using view state encryption unless necessary
12. Consider precompiling
A Web application is batch-compiled on the first request for a resource such as an ASP.NET Web page. If no page in the application has been compiled, batch compilation compiles all pages in a directory in chunks to improve disk and memory usage. You can use the ASP.NET Compilation Tool (Aspnet_compiler.exe) to precompile a Web application. For in-place compilation, the compilation tool calls the ASP.NET runtime to compile the site in the same manner as when a user requests a page from the Web site. You can precompile a Web application so that the UI markup is preserved, or precompile the pages so that source code cannot be changed.
13.Run Web applications out-of-process on Internet Information Services 5.0
By default, ASP.NET on IIS 5.0 will service requests using an out-of-process worker process. This feature has been tuned for fast throughput. Because of its features and advantages, running ASP.NET in an out-of-process worker process is recommended for production sites.
14.Recycle processes periodically
You should recycle processes periodically, for both stability and performance. Over long periods of time, resources with memory leaks and bugs can affect Web server throughput, and recycling processes cleans up memory from these types of problems. However, you should balance the need to periodically recycle with recycling too often, because the cost of stopping the worker process, reloading pages, and re-obtaining resources and data can override the benefits of recycling.
ASP.NET Web applications running on Windows Server 2003, which uses IIS 6.0, do not need to have the process model setting adjusted because ASP.NET will use the IIS 6.0 process model settings.
15.Adjust the number of threads per worker process for your application if necessary
The request architecture of ASP.NET tries to achieve a balance between the number of threads executing requests and available resources. The architecture allows only as many concurrently executing requests as there is CPU power available. This technique is known as thread gating. However, there are conditions in which the thread-gating algorithm does not work well. You can monitor thread gating in the Windows Performance monitor using the Pipeline Instance Count performance counter associated with the ASP.NET Applications performance object.
When an ASP.NET Web page calls an external resource, such as when performing database access or XML Web service requests, the page request generally stops until the external resource responds, freeing the CPU to process other threads. If another request is waiting to be processed and a thread is free in the thread pool, the waiting request begins processing. The result can be a high number of concurrently executing requests and many waiting threads in the ASP.NET worker process or application pool, which hinders the Web server's throughput, adversely affecting performance.
16.For applications that rely extensively on external resources, consider enabling Web gardening on multiprocessor computers
17.Disable debug mode
Always disable debug mode before deploying a production application or conducting any performance measurements. If debug mode is enabled, the performance of your application can suffer
18.Avoid single-threaded apartment (STA) COM components
By default, ASP.NET does not allow STA COM components to run in a page. To run them, you must include the ASPCompat=true attribute in the @ Page directive in the .aspx file. This switches the thread pool used for page execution to an STA thread pool, while also making the HttpContext and other built-in objects available to the COM object. Avoiding STA COM components is a performance optimization because it avoids any call marshaling from multithreaded apartment (MTA) to STA threads.
19.Do not rely on exceptions in your code
Exceptions can cause performance to suffer significantly, so you should avoid using them as a way to control normal program flow. If it is possible to detect in code a condition that would cause an exception, do so rather than catching the exception itself and handling the condition. Common scenarios to detect in code include checking for null, assigning a value to a String that will be parsed into a numeric value, or checking for specific values before applying math operations. The following example demonstrates code that could cause an exception and code that tests for a condition. Both produce the same result.
Not all applications or pages require per-user session state; you should disable session state if it is not needed. To disable session state for a page, set the EnableSessionState attribute the the Page Directive to false.
<%@ Page EnableSessionState=false%>
7.Choose the appropriate session-state provider for your application needs
ASP.NET provides multiple ways to store session data for your application: in-process session state, out-of-process session state as a Windows service, and out-of-process session state in a SQL Server database. Each has its advantages, but in-process session state is by far the fastest solution. If you are storing only small amounts of volatile data in session state, it is recommended that you use the in-process provider. Out-of-process session state options are useful if you scale your application across multiple processors or multiple computers, or where you would like to retain session data if a server or process is restarted
8.Use SQL Server and stored procedures for data access
Of all the data access methods provided by the .NET Framework, using SQL Server for data access is the recommended choice for building high-performance, scalable Web applications. When using the managed SQL Server provider, you can get an additional performance boost by using compiled stored procedures wherever possible instead of SQL commands. For information about using SQL Server stored procedures
9.Use the SqlDataReader class for a fast forward-only data cursor
The SqlDataReader class provides a forward-only data stream retrieved from a SQL Server database. If you can use a read-only stream in your ASP.NET application, the SqlDataReader class offers higher performance than the DataSet class.
10.Cache data and page output whenever possible
ASP.NET provides mechanisms for caching page output or data when they do not need to be computed dynamically for every page request. In addition, designing pages and data requests to be cached, particularly in areas of your site where you expect heavy traffic, can optimize the performance of those pages. Using the cache appropriately can improve the performance of your site more than using any other feature of the .NET Framework.
When using ASP.NET caching, note the following. First, do not cache too many items. There is a memory cost for caching each item. Items that are easily recalculated or rarely used should not be cached. Second, do not assign cached items a short expiration time. Items that expire quickly cause unnecessary turnover in the cache and can cause extra work for cleanup code and for the garbage collector. You can monitor the turnover in the cache due to items expiring by using the Cache Total Turnover Rate performance counter associated with the ASP.NET Applications performance object. A high turnover rate can indicate a problem, especially when items are removed before they expire. (This situation is sometimes known as memory pressure.)
11.Avoid using view state encryption unless necessary
12. Consider precompiling
A Web application is batch-compiled on the first request for a resource such as an ASP.NET Web page. If no page in the application has been compiled, batch compilation compiles all pages in a directory in chunks to improve disk and memory usage. You can use the ASP.NET Compilation Tool (Aspnet_compiler.exe) to precompile a Web application. For in-place compilation, the compilation tool calls the ASP.NET runtime to compile the site in the same manner as when a user requests a page from the Web site. You can precompile a Web application so that the UI markup is preserved, or precompile the pages so that source code cannot be changed.
13.Run Web applications out-of-process on Internet Information Services 5.0
By default, ASP.NET on IIS 5.0 will service requests using an out-of-process worker process. This feature has been tuned for fast throughput. Because of its features and advantages, running ASP.NET in an out-of-process worker process is recommended for production sites.
14.Recycle processes periodically
You should recycle processes periodically, for both stability and performance. Over long periods of time, resources with memory leaks and bugs can affect Web server throughput, and recycling processes cleans up memory from these types of problems. However, you should balance the need to periodically recycle with recycling too often, because the cost of stopping the worker process, reloading pages, and re-obtaining resources and data can override the benefits of recycling.
ASP.NET Web applications running on Windows Server 2003, which uses IIS 6.0, do not need to have the process model setting adjusted because ASP.NET will use the IIS 6.0 process model settings.
15.Adjust the number of threads per worker process for your application if necessary
The request architecture of ASP.NET tries to achieve a balance between the number of threads executing requests and available resources. The architecture allows only as many concurrently executing requests as there is CPU power available. This technique is known as thread gating. However, there are conditions in which the thread-gating algorithm does not work well. You can monitor thread gating in the Windows Performance monitor using the Pipeline Instance Count performance counter associated with the ASP.NET Applications performance object.
When an ASP.NET Web page calls an external resource, such as when performing database access or XML Web service requests, the page request generally stops until the external resource responds, freeing the CPU to process other threads. If another request is waiting to be processed and a thread is free in the thread pool, the waiting request begins processing. The result can be a high number of concurrently executing requests and many waiting threads in the ASP.NET worker process or application pool, which hinders the Web server's throughput, adversely affecting performance.
16.For applications that rely extensively on external resources, consider enabling Web gardening on multiprocessor computers
17.Disable debug mode
Always disable debug mode before deploying a production application or conducting any performance measurements. If debug mode is enabled, the performance of your application can suffer
18.Avoid single-threaded apartment (STA) COM components
By default, ASP.NET does not allow STA COM components to run in a page. To run them, you must include the ASPCompat=true attribute in the @ Page directive in the .aspx file. This switches the thread pool used for page execution to an STA thread pool, while also making the HttpContext and other built-in objects available to the COM object. Avoiding STA COM components is a performance optimization because it avoids any call marshaling from multithreaded apartment (MTA) to STA threads.
19.Do not rely on exceptions in your code
Exceptions can cause performance to suffer significantly, so you should avoid using them as a way to control normal program flow. If it is possible to detect in code a condition that would cause an exception, do so rather than catching the exception itself and handling the condition. Common scenarios to detect in code include checking for null, assigning a value to a String that will be parsed into a numeric value, or checking for specific values before applying math operations. The following example demonstrates code that could cause an exception and code that tests for a condition. Both produce the same result.
No comments:
Post a Comment