ASP. NET 4 new features (1) Core ASP. NET services

1. scalable output Cache

Since ASP. NET 1.0 was released, pages, controls, and HTTP responses are generally stored in the memory by using the output cache. For subsequent Web requests, ASP. NET can retrieve the cached output from the memory rather than re-generating the output from the beginning to provide a faster response. However, this method has a limit that the cached data must be stored in the memory. On a server with a large load, the memory requirements of the output cache may conflict with the memory requirements of other parts of the web application.

ASP. NET 4 adds scalability to the output cache, allowing you to configure one or more custom output cache providers. The output cache provider can use any storage mechanism to save HTML content. These storage options include local or remote disks, cloud storage, and distributed cache engines.

With ASP. NET 4, you can customize the function of the output cache provider, so that we can design a more active and intelligent output Cache Policy for the website. For example, we can create an output cache provider that caches the top 10 pages of website traffic in the memory and other pages in the disk. Alternatively, you can cache the combinations of various change factors on the displayed page, but you should use distributed cache to reduce the memory consumption of the front-end web server.

We can create a class that inherits from the outputcacheprovider type to customize the output cache provider. Then, you can configure the provider in Web. config and set the providers subnode of the outputcache node, as shown in the following example:

<Caching>
<Outputcache defaultprovider = "aspnetinternalprovider">
<Providers>
<Add name = "diskcache"
Type = "test. outputcacheex. diskoutputcacheprovider, diskcacheprovider"/>
</Providers>
</Outputcache>
</Caching>

In the default output Cache Policy of ASP. NET 4. All HTTP responses, displayed pages, and control caches use the default output cache provider shown in the preceding example (the defaultprovider attribute value is aspnetinternalprovider ). You can specify different providers for defaprovider provider. You can change the default output cache provider of Web applications.

In addition, you can select different output cache providers for each user control and each request. To select different output cache providers for different Web user controls, the easiest way is to set the providername attribute added to the page or control commands, as shown in the following example:

<%@ OutputCache Duration="60" VaryByParam="None" 
    providerName="DiskCache" %>

To specify different output cache providers for an HTTP request, you can overwrite the newly added getoutputcacheprovidername method in the global. asax file and specify the provider to be used for the specific request programmatically.

2. Pre-load Web Applications

Some Web applications need to load a large amount of data or perform initialization processing with a high overhead before they request to provide services for the first time. In earlier versions of ASP. NET, you must use a custom method to "wake up" ASP. NET applications, and then run the initialization code in the application_load method in the global. asax file.

To cope with this situation, ASP. NET 4 provides a new application preload manager when it runs in iis7.5 on Windows Server 2008 R2. The pre-loading function provides a controllable method for starting the application pool, initializing ASP. NET applications, and then receiving HTTP requests. In this way, you can perform initialization of an application with a high overhead before processing the first HTTP request. For example, you can use the pre-load manager to initialize an application, and then send a signal to the Load balancer to inform the application that it has been initialized and is ready to accept HTTP requests.

To use the application preload manager, you need to configure the applicationhost. config file and set the application pool in IIS 7.5 to automatically start. The configuration is as follows:

<Applicationpools>
<Add name = "myapplicationpool" startmode = "alwaysrunning"/>
</Applicationpools>

Because an application pool can contain multiple applications, we need to specify the applications to be automatically started by using the following configurations in the applicationhost. config file:

<Sites>
<Site name = "mysite" id = "1">
<Application Path = "/"
Serviceautostartenabled = "true"
Serviceautostartprovider = "prewarmmycache">
<! -- Additional content -->
</Application>
</Site>
</Sites>

<! -- Additional content -->

<Serviceautostartproviders>
<Add name = "prewarmmycache"
Type = "mynamespace. custominitialization, mylibrary"/>
</Serviceautostartproviders>

3. Permanent redirect page

During the application lifecycle, web applications may modify the URL display rules.

In ASP. NET, the traditional method for developers to process requests to old URLs is to use the Redirect method to forward requests to new URLs. However, the Redirect method will issue a temporary HTTP 302 redirection. This will generate additional HTTP round-trips. It is not friendly to search engines.

ASP. NET 4 adds a redirectpermanent help method, which can easily respond to HTTP 301 (permanent redirect), as shown in the following example:

RedirectPermanent("/newpath/foroldcontent.aspx");

4. session state Compression

By default, ASP. NET provides the option to store the session Status of the entire web application. The first option is a session Status provider that calls an out-of-process session Status server. The second option is a session Status provider that stores data in the Microsoft SQL Server database.

Since both options store status information outside of the Web application's working process, you must serialize the session status before sending it to remote storage. If a large amount of data is stored in the session state, the size of serialized data may become large.

ASP. NET 4 introduces a new compression option for these two types of off-process session state providers. With this option, applications with excessive CPU cycles on the Web server can greatly reduce the size of serialized session state data.

You can use the newly added compressionenabled attribute of the sessionstate element in the configuration file to set this option. When the compressionenabled configuration option is set to true, ASP. NET uses the. NET Framework gzipstream class to compress and decompress the serialized session status. The following example shows how to set this feature.

<Sessionstate
Mode = "sqlserver"
Sqlconnectionstring = "Data Source = dbserver; initial catalog = aspnetstate"
Allowcustomsqldatabase = "true"
Compressionenabled = "true"
/>