ASP.NET Performance Best Practices
Author：Eve Cole
Update Time：2009-06-30 16:04:02
Organize logical/physical design practice recommendations based on MSDN webcast: Use logical three-tier model pages (.aspx) and user controls (.ascs)
Reusable types (components) are placed in the bin directory. Data is placed in a SQL database. Recommended: Design for Web Farm. Do not assume that visitors will always return to the same server. Pay attention to static variables and application state.
Web Farm session state recommendations: Using the same process should avoid (when possible):
Synchronous calls to XML Web services using XML Web services through remote calls through DCOM:
Communication between applications on the Internet should not be used for intra-application communication. Recommendation: Use ISA Server, when a DMZ security zone is required:
Allow access only via ISA
ISA tunnel through DMZ to ASP.NET
Reduce process switching language/code recommendations to avoid using late binding
<%@ Page Language = "VB" Explicit = "true" %> requires declaration of all variable types and still allows late binding
<%@ Page Language = "VB" strict = "true" %>Prohibits the use of any late binding
It is recommended to use COM as little as possible for COM interaction, and to use managed component data it is recommended to store the data in SQL Server and choose the appropriate data access method: OLEDB/SQL client/ODBC
Reasonably choose DataSet and DataReader for data access state management and choose the appropriate way to store Session: Inproc/StateServer/database
Use simple data types to avoid saving STA's COM objects in the Session. If the Session is not needed, disable it: EnableSessionState = "false"
If possible, use the readonly attribute: EnableSessionState = "Readonly"
If ViewState is not needed, disable it, EnableViewState = false
Minimize the data in ViewState View the size of ViewState View the HTML output source code or enable Trace
Use Cache Page Cache Partial Page Cache
Cache object data cache
WebService cache method to quantify WEB performance: Machine throughput response time Tested by loading the server Using multiple client machines to load free Microsoft Web Application Stress
Test multiple scenarios to simulate the end-to-end scenario traversal of the site. Test single page performance. Values that need to be calculated. Request/sex under different loads (100, 250, 500, 750, 1000, etc. customers visiting at the same time)
Identifies maximum client load within acceptable TTFB/TTLB response time Critical performance counters Processor, CPU % Utilization || Low values = exposure or lock contention
ASP.NET, number of enqueued requests || Linear growth means the server is fully loaded
ASP.NET application, requests per second||Dynamic throughput (should be consistent)
ASP.NET application, total number of errors || Indicates functional errors (should be 0)
ASP.NET application, worker process restart || Indicates a serious functional error
