Asp. NET caching method analysis and practice example

Add caching support to the data tier, business logic tier, UI, or output layer. Memory is now very cheap-therefore, a great performance improvement can be achieved by implementing caching in the entire application in an intelligent manner. Caching can mask many of the fault caches as a way to get "good enough" performance without a lot of time and analysis.

Again, the emphasis here memory is now very cheap, so if you can get the performance you need by caching the output for 30 seconds instead of trying to optimize the code or the database for a whole day or even a week, you will definitely choose to cache the solution (assuming you can accept 30 seconds of old data). Caching is one of those features that uses 20% to get 80% returns, so to improve performance, you should think of caching first.

However, if the design is bad and the end result is likely to have undesirable consequences, you should, of course, design the application as well as possible. But if you just need to get high enough performance immediately, caching is your best option, and you can redesign your application as soon as you have time later. Page-level output caching is the simplest form of caching in which the output cache retains only a copy of the HTML sent in response to the request in memory. Subsequent requests will provide cached output until the cache expires, so that performance can be significantly improved (depending on how much overhead is required to create the original page output – the output of the cache is always fast and relatively stable). Implementation to achieve the page output cache, as long as a OutputCache instruction to add to the page.
Copy CodeThe code is as follows:
<%@ OutputCache duration= "60″varybyparam=" * "%>

As with other page directives, the directive should appear at the top of the ASPX page, before any output.　 It supports five properties (or parameters), of which two are required. Duration Required Properties. The time, in seconds, that the page should be cached. Must be a positive integer. Location specifies where the output should be cached. If you want to specify this parameter, you must be one of the following: Any, Client, downstream, None, Server, or serverandclient. VaryByParam Required Properties. The name of the variable in Request, which should produce a separate cache entry. "None" indicates no change. The "*" can be used to create a new cache entry for each variant array. separated by ";" between variables. VaryByHeader changes the cached entry based on the changes in the specified header.

VaryByCustom allows custom changes to be specified in Global.asax (for example, "Browser"). Use a combination of the required Duration and VaryByParam options to handle most situations. For example, if your product catalog allows users to view catalog pages based on CategoryID and page variables, you can use the parameter value "CategoryID;" Page "VaryByParam the product catalog for a period of time (if the product is not changing at any time, an hour is acceptable, so the duration is 3,600 seconds). This creates a separate cache entry for each catalog page of each kind. Each entry will be maintained for one hours from its first request. VaryByHeader and VaryByCustom are primarily used to customize the appearance or content of a page based on the client accessing the page. The same URL may need to render output for both the browser and the mobile client, so different content versions are cached for different clients.

Alternatively, the page may have been optimized for IE, but it needs to be able to completely reduce optimizations (rather than just damaging pages) against Netscape or Opera. The latter example is very common, and we will provide an example of how to achieve this: example: VaryByCustom is used to support browser customization in order for each browser to have a separate cache entry, the VaryByCustom value can be set to "browser". This feature is already built into the cache module, and a separate page cache version is inserted for each browser name and major version.
Copy CodeThe code is as follows:
<%@ OutputCache duration= "60″varybyparam=" None "varybycustom=" browser "%>"

Fragment caching, the user control output cache caching of an entire page is not usually feasible, because some parts of the page are customized for the user. However, other parts of the page are common to the entire application. These sections are best used for caching with fragment caching and user controls. Menus and other layout elements, especially those that are dynamically generated from the data source, should also be cached in this way. If you want, you can configure the cached control to change based on changes to its controls (or other properties) or any other changes supported by the page-level output cache. Hundreds of pages that use the same set of controls can also share cached entries for those controls, rather than reserving separate cached versions for each page. Implementing fragment caching uses the same syntax as page-level output caching, but it applies to user controls (. ascx files) instead of Web forms (. aspx files). In addition to the Location property, the user control is also supported for all properties that OutputCache supports on Web forms. The user control also supports the OutputCache property named VaryByControl, which changes the cache of the control based on the value of the user control, which is typically a member of a control on the page, for example, DropDownList.

If you specify a VaryByControl, you can omit VaryByParam. Finally, by default, each user control on each page is cached separately. However, if a user control does not change with the page in the application and the same name is used on all pages, you can apply the shared= "true" argument, which will make the cached version of the user control available to all pages that reference the control. Example
Copy CodeThe code is as follows:
<%@ OutputCache duration= "60″varybyparam=" * "%>

The example caches the user control for 60 seconds, and creates a separate cache entry for each change to the query string for each page on which the control is located. asp.net
Copy CodeThe code is as follows:
<%@ OutputCache duration= "60″varybyparam=" None "Varybycontrol=" Categorydropdownlist "%>"

The example caches the user control for 60 seconds and creates a separate cache entry for each distinct value of the categorydropdownlist control, and for each page that contains the ASP.net control.
Copy CodeThe code is as follows:
<%@ OutputCache duration= "60″varybyparam=" None "varybycustom=" Browser "shared=" True%>

Finally, the example will asp.net cache the user control for 60 seconds, and a cache entry will be created for each browser name and major version. The cached entries for each browser are then shared by all pages that reference the user control (as long as all pages refer to the control with the same ID). Page-level and user-control-level output caching is indeed a way to quickly and easily improve site performance, but the true flexibility and power of the asp.net cache is provided through the cache object. With the cache object, you can store any serializable data objects, based on a combination of one or more dependencies, to control how the cached entries expire. These dependencies can include the time elapsed since the item was cached, the time elapsed since the item was last accessed, changes to files and/or folders, and changes to other cached items, which can also include changes to a particular table in the database after a slight processing.