Analysis on ASP. NET code optimization

ASP. NET code optimization I. Page and Server Control Processing

1. ASP. NET code optimization avoids unnecessary round-trips to the server

In some cases, you do not need to use the ASP. NET Server Control and execute the send-back event processing. For example, verifying user input on an ASP. NET webpage can often be performed on the client before the data is submitted to the server. Generally, if you do not need to pass the information to the server for verification or write it into the data storage area, avoid using the code that causes the round-trip to the server, this improves the page performance and user experience. You can also use the client callback to read data from the server instead of performing the entire round-trip.

The page class implements the ICallbackEventHandler interface and registers the GetCallbackEventReference method, that is, ajax callback implementation.

For a page that requires loading many controls (loading time-consuming pages), we can use ajax technology to improve page access performance.

2. ASP. NET code optimization uses the IsPostBack attribute of the Page object to avoid unnecessary handling of the round-trip

If you write the code that processes the Server Control sending back, sometimes the code may only be executed on the first request page, instead of every sending back. Use the IsPostBack attribute to execute code conditionally based on whether the page is generated in response to the server control event.

Place the code that needs to be executed when the page is requested for the first time in the IsPostBack condition.

3. ASP. NET code optimization only saves the Server Control view status when necessary

The automatic view status management enables the server controls to re-fill their attribute values during the round-trip, without writing any code. However, this function affects performance because the view status of the server control is redirected to and from the server in the hidden form field. It is helpful to know under which circumstances the view status will be helpful and under which circumstances it will affect the page performance. For example, if you bind a server control to data on each round trip, because the value of the control will be replaced with a new value during data binding, the saved view status is useless. In this case, disabling the view State can save processing time and reduce the page size.

By default, view status is enabled for all server controls. To disable it, set the EnableViewState attribute of the control to false.

You can also use the @ Page command to disable the view status of the entire Page. This is useful when you do not send a page back to the server.

The @ Control command also supports the EnableViewState attribute to specify whether the view State is enabled for the user Control.

View status:

To analyze the size of the view State used by the server control in the Page, enable tracing for this Page by including the trace = "true" attribute in the @ Page command. Then, in the trace output, view the "Viewstate" column in the "control hierarchy" table.

Viewstate can be disabled in the following cases:

1) Page Control. ascx)

2) The page is not returned to itself.

3) You do not need to process control events.

4) The control does not have dynamic or data-bound attribute values or is processed in the code for each postpack)

4. ASP. NET code optimization: Leave the buffer closed for special reasons to keep it open.

Disabling the buffer of ASP. NET web pages results in a large amount of performance overhead.

5. ASP. NET code optimization Server. Transfer and Response. Redirect

Response. Redirect simply tells the browser to access another page. Server. Transfer helps reduce Server requests and keep the address bar URL unchanged. It allows you to pass the query string and form variables to another page to hide the parameters passed in the url.

Response. Redirect can jump across sites, and Server. Transfer can only jump to the same site.

Microsoft ASP. NET code optimization suggestions:

Redirect between different ASP. NET pages in the same application using a Transfer Server object or cross-page sending Method

If there are no special requirements, Server. Transfer should be selected first for page Jump

ASP. NET code optimization II. Data Access

1. ASP. NET code optimization uses SQL Server and stored procedures for data access

Among all the data access methods provided by. NET Framework, using SQL Server for data access is a recommended choice for generating high-performance, scalable Web applications. When using a hosted SQL Server Provider, you can use compiled stored procedures instead of SQL commands as much as possible for additional performance improvement.

Select SQL Server only for the database. If the database is another one, ignore this option)

2. ASP. NET code optimization: Use the SqlDataReader class for fast data-only cursor

The SqlDataReader class provides only inbound data streams retrieved from the SQL Server database. If you can use read-only streams in ASP. NET applications, the SqlDataReader class provides higher performance than the DataSet class. The SqlDataReader class uses the Local Network Data Transmission Format of SQL Server to directly read data from the database connection. For example, when bound to the SqlDataSource control, you can achieve better performance by setting the DataSourceMode attribute to DataReader. Using a data reader may lead to loss of some features .) In addition, the SqlDataReader class implements the IEnumerable interface, which allows you to bind data to server controls.

(Select SQL Server only for the database. If the database is another one, you can ignore this option.) MySql corresponds to MySqlDataReader and select as needed.

3. Optimize ASP. NET code to cache data and page output as much as possible

ASP. NET provides some mechanisms to cache the output or data of these pages when you do not need to request dynamic computing page output or data for each page. In addition, you can optimize the performance of pages and data requests to be cached, especially in areas where the site is expected to have a large amount of communication. Compared with any other functions of. NET Framework, using the cache appropriately can improve the performance of the website.

Note the following when using ASP. NET cache. First, do not cache too many items. Each item in the cache has a memory overhead. Do not cache items that are easy to recalculate and rarely used. Second, the period of validity allocated to cache items should not be too short. Items that expire soon will cause unnecessary turnaround in the cache, and cause additional code clearing and garbage collection. You can use the "Cache Total Turnover Rate" Cache Total circulation Rate associated with the "ASP. NET Applications" performance object) performance counters to monitor the Turnover caused by expiration of items in the Cache. High turnover rate may indicate problems, especially when items are removed before expiration. This is sometimes called memory pressure .)

You can consider putting static, slightly changed, or infrequently changed content that requires dynamic loading into the control and using the cache technology.

<%@ OutputCache Duration = "100" VaryByParam = "none" %>

4. Optimize ASP. NET code and properly use SQL cache Dependencies

ASP. NET also supports table-based round robin and query notifications, depending on the version of the SQL Server used. All SQL Server versions support table-based round robin. In table-based round robin, if any content in the table is changed, all listeners will become invalid. This may cause unnecessary changes in the application. We recommend that you do not use table-based round robin For tables with many frequent changes. For example, we recommend that you use table-based round robin for directory tables with few changes. We recommend that you do not use table-based round robin For order tables. Order tables are updated more frequently. SQL Server 2005 supports query notifications. Query notifications support specific queries to reduce the number of notifications sent when the table is changed. Although it provides better performance than table-based round robin, it cannot be extended to accommodate thousands of queries.

(Select SQL Server only for the database. If the database is another one, you can ignore this option)

5. Use Data Source paging and sorting instead of UI user interface for ASP. NET code optimization)

The UI paging function of data controls such as DetailsView and GridView can be used to support any data source objects of the ICollection interface. For each paging operation, the Data Control queries the entire dataset of the data source, selects the row to be displayed, and discards the remaining data. If the data source implements performanceview and the CanPage attribute returns true, the data control uses the data source paging instead of the UI paging. In this case, the data control only queries the rows required for each paging operation. Therefore, data source paging is more efficient than UI paging. Only the ObjectDataSource data source control supports data source paging. To enable data source paging on other data source controls, you must inherit from the data source control and modify its behavior.

6. ASP. NET code optimization balance security benefits and performance overhead of event Verification

Controls derived from the System. Web. UI. WebControls and System. Web. UI. HtmlControls classes can verify that the event is derived from the user interface presented by the control. This helps prevent the control from responding to forged Event Notifications. For example, the DetailsView control can prevent Delete operations. The call control does not support this operation in nature. This verification results in certain performance overhead. You can use the EnableEventValidation configuration element and the RegisterForEventValidation method to control this behavior. The overhead of the verification depends on the number of controls on the page, which is within a few percent.

We strongly recommend that you do not disable event verification. Before disabling event verification, make sure that no sending back that may have an unexpected impact on the application is constructed.

7. ASP. NET code optimization. Do not use view State encryption unless necessary.

View state encryption prevents users from reading values in the hidden view State field. A typical scenario is the GridView control with an Identifier Field in the DataKeyNames property. The Identifier Field is required to coordinate record updates. Because you do not want the identifier to be visible to the user, you can encrypt the view status. However, encryption has a constant performance overhead for initialization and additional overhead depending on the size of the encrypted view State. Encryption is set for each page load, so the same performance impact occurs during each page load.

8. Use SqlDataSource to cache, sort, and filter ASP. NET code optimization

If the DataSourceMode attribute of the SqlDataSource control is set to DataSet, SqlDataSource can cache the query result set. If data is cached in this way, the filter and sort operations of the control are configured using the FilterExpression and SortParameterName attributes. The cached data is used. In many cases, if you cache the entire dataset and use the FilterExpression and SortParameterName attributes for sorting and filtering, instead of using SQL queries with the "WHERE" and "SORT BY" clauses for these queries, the application runs faster.

(Only some databases are supported based on specific controls)

ASP. NET code optimization is introduced here. I hope you will understand ASP. NET code optimization through this article.

1. Analysis on five common controls for ASP. NET data verification
2. Some discussions about ASP. NET code separation
3. Experience in ASP. NET code separation
4. Detailed research on ASP. NET data verification technology
5. Application of ASP. NET code separation in website construction