Performance Try Tips Any programming model has a common performance defect, ASP.NET is no exception. This section describes some ways to avoid performance bottlenecks in the code.
1. Disable session status when not used: Not all applications or pages require a session state based on each user. If you don't need it, you can completely disable it. This can be easily implemented by the following page level instructions: <% @ Page EnableSessionState = "false"%>
Note: If the page needs to access the session variable but do not create or modify them, set the command value to readonly. Session status can also be disabled for XML Web service methods. See the use objects and internal objects in the XML Web Services section.
2. Carefully select the session status provider: ASP.NET provides three different methods for the storage application's session data: the session state in the process, as the process of the Windows service, and the process of processes in the SQL database. Each method has its own advantages, but the process of session in the process is the fastest speed to date. If you still store less volatile data only in the session state, you should use the program in the process. Process external solutions are mainly used for web gardens and web farm programs, or if the data cannot be lost when the server / process is restarted. 3. Avoid excessive round trip between the server: Web Forms Framework is one of the best features of ASP.NET because it can significantly reduce the amount of code required to complete a task. Page element programming access using the Server Control and Retreat Event Processing Model is undoubtedly the most cost-time function. However, there is an appropriate and inappropriate method for the use of these functions, and it is important to understand when they are appropriate. Applications typically need to go to and from servers only when retrieving data or store data. Most data operations can be done between the client at the round trip. For example, you can usually verify the form item in the client before the user is submitted. Typically, if you don't need to follow the server back to the server, you should not go to the server. If you write your own server control, consider rendering the client code for the upper level (supporting the ECMAScript) browser. By adopting the "intelligent" control, you can significantly reduce the number of unnecessary clicks on the web server. 4. Use Page.isPostback to avoid additional work on the round trip: If the process server control is sent, you usually need to execute the code when the first request page is different from the code used for the round trip when the event is excited. If you check the page.ispostback property, the code can be executed according to the condition, depending on whether there is an initial request to the page or a response to the server control event. This seems to be obvious, but it can actually ignore this check without changing the page.
