ASP. NET uses cache technology to speed up Website access

ASP. NET provides three main forms of cache: page-level output cache, user control-level output cache (or segment cache), and cache API. The advantage of output cache and fragment cache is that it is very easy to implement. In most cases, it is sufficient to use these two caches. The cache API provides additional flexibility (in fact, it is quite flexible) and can be used to exploit the cache at each layer of the application. This article comprehensively introduces the application of these three caching technologies in all layers of the system.

Among the many features provided by ASP. NET, cache support is undoubtedly my favorite feature. I have a good reason to say so. Compared with ASP. all other features of. NET, the cache has the greatest potential impact on the application performance, using the cache and other mechanisms, ASP. NET developers can accept the additional overhead when building a site using a control with a large overhead (for example, DataGrid), without worrying that the performance will be greatly affected. To maximize the use of caching in applications, you should consider implementing caching at all program levels.

Steve's cache prompt

Early cache; frequent Cache

You should implement caching at each layer of the application. Add cache support to the data layer, business logic layer, UI, or output layer. Memory is currently very cheap-therefore, implementing caching in the entire application in a smart way can greatly improve performance.

Cache can prevent many mistakes

Caching is a way to achieve "good enough" performance without much time and analysis. The memory is very cheap now, so if you can cache the output for 30 seconds, instead of spending a whole day or even a week trying to optimize the code or database to get the required performance, you will definitely choose a cache solution (assuming you can accept 30 seconds of old data ). Cache is one of the features that get a 20% return Using 80%. Therefore, to improve performance, you should first think of cache. However, if the design is poor, it may lead to adverse consequences. Therefore, you should, of course, try to design the application correctly. However, if you only need to obtain high performance immediately, the cache is your best choice. You can redesign the application in the future.

Page-level output Cache

As the simplest form of caching, the output cache only retains the HTML copies sent in response to the request in the memory. When there are other requests, the cache output will be provided until the cache expires. In this way, performance may be greatly improved (depending on the overhead required to create the original page output-the output of the sending cache is always fast and stable ).

Implementation

To implement the page output cache, you only need to add an OutputCache command to the page.

<% @ OutputCache Duration = "60" VaryByParam = "*" %>

Like other page commands, this command should appear at the top of the ASPX page, that is, before any output. It supports five attributes (or parameters), two of which are required.

Duration Required attribute. The time when the page should be cached, in seconds. Must be a positive integer.

Location specifies the Location where the output should be cached. To specify this parameter, it must be Any, Client, Downstream, None, Server, or ServerAndClient.

Required attribute of VaryByParam. The name of the variable in the Request. These variable names should generate separate cache entries. "None" indicates no change. "*" Can be used to create a cache entry for each variable group. Variables are separated.

VaryByHeader changes cache entries based on changes in the specified header.

VaryByCustom allows you to specify custom changes (for example, "Browser") in global. asax ").

The combination of the required Duration and VaryByParam options can be used to handle most cases. For example, if your product directory allows users to view the directory Page Based on categoryID and page variables, you can set the parameter value to "categoryID; page "VaryByParam caches the product directory for a period of time (if the product is not changed at any time, one hour is acceptable, so the duration is 3600 seconds ). This creates separate cache entries for each directory page of each category. Each entry is counted from its first request for one hour.

VaryByHeader and VaryByCustom are mainly used to customize the appearance or content of the page based on the client accessing the page. The same URL may need to be rendered and output for both the browser and mobile client. Therefore, different content versions must be cached for different clients. Alternatively, the page may have been optimized for IE. For Netscape or Opera, the optimization function should be canceled. The next example is very common. We will provide an example to illustrate how to achieve this goal:

Example: VaryByCustom is used to support browser customization.

To make each browser have a separate cache entry, the value of VaryByCustom can be set to "browser ". This function has been built into the cache module and will insert a separate page Cache version for each browser name and major version.

<% @ OutputCache Duration = "60" VaryByParam = "None" VaryByCustom = "browser" %>

Segment cache, user control output Cache

• Four pages in total:
• Previous Page
• 1
• 2
• 3
• 4
• Next Page