Http://www.yesky.com/softchannel/7234238046804376/20040731/1837270.shtml
[Article] Author: Steven A. Smith Time: 2004-07-31 Source: MSDN development Featured Editor: Ark
[Document] ASP.NET provides three main forms of cache: page-level output cache, user control level output cache (or fragment cache) and cache API
Text] 1 2 3 4 Next Page
[Introduction] ASP.NET provides three main forms of cache: page-level output cache, user control level output cache (or fragment cache) and cache API. The advantage of output cache and fragment cach is very easy to implement, in most cases, it is sufficient to use these two caches. The cache API provides additional flexibility (actually a considerable flexibility), which can be used to utilize the cache at each layer of the application. This paper has been introduced the application of these three cache techniques in the system layers. In many features provided by ASP.NET, cache support is undoubtedly my most appreciated, I said that it is of course full reason. Compared to all other features of ASP.NET, the cache has the greatest potential impact on the performance of the application, using cache and other mechanisms, ASP.NET developers can accept the use of high-cost controls (for example, DataGrid) build sites. Additional expenses don't worry that performance will be too much affected. To maximize the cache in your application, you should consider how cache is achieved at all program levels. Steve's cache prompts to cache as early as possible; often cache you should cache every layer of the application. Cache support is added to the data layer, the business logic layer, the UI, or the output layer. Memory is now very cheap now - therefore, by achieving caches throughout the application through intelligence, it can be improved. Cache prevents many negligence caches from getting a "sufficiently good" performance without having a large amount of time and analysis. Here again, memory is now very cheap, so if you can get the desired performance by going to the output cache for 30 seconds, not to spend a day or even a week, you can get the desired performance, you will definitely choose a cache. Solution (assuming 30 seconds of old data). Caches are one of the features that use 20% to get 80% return, so we should improve performance and should first think of cache. However, if the design is very bad, it will eventually bring bad consequences, so you must also design the application properly as possible. But if you just need to get a high enough performance, the cache is your best choice, you can re-design the application when you have time. The page-level output cache is the simplest cache form, and the output cache is only a copy of the HTML sent by the response request in the memory. There will then be a request to provide the output of the cache, until the cache expires, this is possible to improve significantly (depending on how much overhead is required to create the original page output - the output of the send cache is always very fast, and compare stable). Implementation To implement the page output cache, just add an OutputCache instruction to the page.
<% @ OutputCache Duration = "60" VaryByParam = "*"%> As with other page instructions, the instruction 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 attributes. The page should be cached, in seconds. Must be positive integers. Location Specifies the location where the output should be cached. If you want to specify this parameter, you must be one of the following options: Any, Client, DownStream, None, Server, or ServerandClient. VaryByParam is required. The name of the variable in the request, these variable names should generate a separate cache entry. "None" means there is no change. "*" Can be used to create a new cache entry for each different variable array. The variable is separated by ";". VarybyHeader changes Cache entries based on changes in the designated header. Varybycustom allows custom changes in Global.asax (for example, "Browser"). Most of the cases can be handled with a combination of required Duration and VarybyParam options. For example, if your product catalog allows users to view directory pages based on CategoryID and page variables, you can use the parameter value "categoryid; page" to cache the product directory for a while (if the product is not changed at any time, one hour can still Accepted, therefore, the duration is 3,600 seconds). This will create a separate cache entry for each directory page of each species. Each entry will be within an hour from its first request. VarybyHeader and VarybyCustom are used to customize the appearance or content of the page based on the client access page. The same URL may need to be output to the browser and mobile phone client, so you need to cache different content versions for different clients. Alternatively, the page may have been optimized for IE. This optimization function should be canceled for Netscape or Opera. The latter example is very common, we will provide an example of how to implement this goal: Example: VarybyCustom is used to support browser to customize to make each browser have a separate cache entry, VarybyCustom's value can be set to "Browser" . This feature has been built into the cache module and will insert a separate page cache version for each browser name and the main version. <% @ Outputcache duration = "60" VarybyParam = "none" varybycustom = "browser"%> ............................. ................................
