ASP. NET Performance Optimization Configuration

The following describes two methods for ASP. NET performance optimization in configuration content: State management and Web application considerations.

ASP. NET performance optimization-state management

A) disable it when the session status is not used.

Not all applications or pages require the session Status of a specific user; you should disable the session status when you do not need it. To disable the Page session Status, set the EnableSessionState attribute in the @ Page command to false.

If the Page needs to access session variables but does not create or modify them, set the EnableSessionState attribute in the @ Page command to ReadOnly.

To disable the session Status of an application, set the Mode attribute to Off in the SessionState section of the application's Web. config file.

B) Select the appropriate session Status provider for application needs

ASP. NET provides multiple methods for storing application session data: in-process session Status, out-of-process session status as a Windows service, and out-of-process session Status in the SQL Server database. You can also create a custom session Status provider to store session data in the selected data storage area .) Each method has its own advantages, but the in-process session status is the fastest solution so far. If you only store a small amount of data that is prone to loss in the session state, we recommend that you use in-process providers. The out-of-process session status option is used to scale applications across multiple processors or computers, or to retain session data when a server or process restarts.

Web applications with ASP. NET performance optimization

A) Consider pre-Compilation

In the first request for resources such as ASP. NET Web pages, Web applications are batch compiled. If no pages are compiled in the application, the batch compilation function will compile all pages in the directory in batches to increase disk and memory usage. You can use ASP. NET compilation tool (Aspnet_compiler.exe) to pre-compile Web applications. For local compilation, this compilation tool calls the ASP. NET Runtime Library to compile the site. The method is the same as when you request a page from the website. Web applications can be pre-compiled to retain the UI tag, or pages can be pre-compiled to prevent source code changes.

B) Remove the dual-connection restrictions on clients

The HTTP specification indicates that an HTTP client and any server can establish up to two TCP connections at the same time. This prevents a single browser from over-loading the Server due to excessive connection requests when browsing a page, for example, with 120 embedded thumbnails.

 
 

  
  
< system.net> 
  
  
   < connectionManager> 
  
  
      < add address="*" maxconnection = "40" /> 
  
  
         …  
 
 

It will speed up the client's access to the page, but it will also increase the server load, the configuration needs to be balanced)

C) run a Web application outside the process on Internet Information Service 5.0

By default, ASP. NET on IIS 5.0 uses an out-of-process auxiliary process to provide services for requests. This feature has been optimized to increase throughput. It is recommended to use ASP. NET on the production site because it has its functions and advantages in the auxiliary process outside the process.

D) Regular recovery process

To ensure stability and performance at the same time, the process should be recycled regularly. After a long period of time, resources with memory leaks and bugs can affect the Web server throughput, while the recycle process can clear the memory to avoid such problems. However, the demand for regular recovery and frequent recovery should be balanced, because the overhead of stopping auxiliary processes, reloading pages, and re-obtaining resources and data may exceed the benefits of recovery.

You do not need to adjust the process model settings for ASP. NET Web applications running on Windows Server 6.0 using IIS 2003 because ASP. NET uses the IIS 6.0 process model settings.

E) Adjust the number of threads for each auxiliary process of the application if necessary.

The request structure of ASP. NET tries to strike a balance between the number of threads executing the request and the available resources. This structure determines the number of requests that can be executed simultaneously based on the CPU power available for requests. This technology is called thread-control. However, in some conditions, the thread-control algorithm is not very effective. By using the "Pipeline Instance Count" Pipeline Instance Count associated with the "ASP. NET Applications" performance object) performance counters, You can monitor thread-control in Windows performance monitor.

When ASP. NET Web pages call external resources, such as executing database access or XML Web services requests), page requests usually stop and release the CPU to process other threads until the external resources respond. If another request is waiting for processing and a thread in the thread pool is released, it starts to process the waiting request. This may cause ASP. there are a large number of concurrent requests and many waiting threads in the NET auxiliary process or application pool, and they will affect the Web server throughput and thus adversely affect the performance.

To alleviate this problem, you can manually set the number of threads in the process by changing the MaxWorkerThreads and MaxIOThreads attributes in the processModel section of the Machine. config file.

Auxiliary threads are used to process ASP. NET requests, while IO threads are used to provide services for data from files, databases, or XML Web services.

The value assigned to the process model attribute is the maximum number of threads of each CPU type in the process. For dual-processor computers, the maximum number is twice the set value. For a four-processor computer, the maximum value is four times the set value. The default value can be used for computers with one or two processors. However, for computers with more than two processors, 100 or 200 threads in a process may cause more disadvantages. Because of the extra context switch, the operating system spends the CPU cycle on the maintenance thread rather than processing the request, so too many threads in the process will often reduce the server speed. The proper number of threads should be determined through the performance test of the application.

F) disable the debugging mode.

Debug mode is always disabled before you deploy production applications or perform any performance measurements. If the debug mode is enabled, the performance of the application may be affected.

 
 

  
  
< system.web> 
  
  
   < compilation debug="false"> 
  
  
…  
 
 

G) Optimize the configuration files for Web server computers and specific applications to meet your needs.

By default, ASP. NET configuration is set to enable the widest set of functions and adapt to the most common situations as much as possible. You can change some default configuration settings to improve application performance, depending on the features you use.

1) only enable authentication for the desired application

By default, the authentication mode of ASP. NET applications is Windows or integrated NTLM. In most cases, it is best to disable authentication only for applications that require authentication in the Machine. config file and enable authentication in the Web. config file.

2) configure the application based on the appropriate request and response encoding settings

ASP. NET default encoding format is UTF-8. If your application only uses ASCII characters, configure your ASCII application for a slight performance improvement.

3) Disable AutoEventWireup for Applications

In the Machine. config file, set the AutoEventWireup attribute to false, meaning that the page will not bind the page event to a method based on name matching, such as Page_Load ). If AutoEventWireup is disabled, the page will be slightly improved by leaving the event connection to you instead of automatically executing it.

To process page events, you can use either of the two policies. The first policy is to override the methods in the base class. For example, you can rewrite the OnLoad method of the Page object for the Page loading event, instead of using the Page_Load method. You must call the base method to ensure that all events are triggered .) The second method is to bind the Handles keyword in Visual Basic or the delegate connection in C # to the event.

4) Remove unused modules from the request processing pipeline

By default, all functions of the HttpModules node in the Machine. config file of the server computer remain active. Based on the features used by the application, you can remove unused modules from the request pipeline for a slight performance improvement. Check each module and its functions and customize it as needed. For example, if you do not use session Status and output cache in an application, you can remove them from the HttpModules list so that requests do not perform other meaningful processing, you do not have to call these modules.

This article is from shllove's column ASP. NET performance optimization.

1. The simplest ASP. NET performance monitoring tool
2. Some misunderstandings about. NET performance and the relationship between C # and VB. NET
3. Lambda expressions: Do you need clear code for performance?
4. Analysis of methods to improve the performance of GDI Programming
5. Use Cache to improve ASP. NET performance