Shulou(Shulou.com)06/02 Report--

Today, I will talk to you about the suggestions on the use of ASP.NET cache, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following for you. I hope you can get something from this article.

Cache early; cache often you should implement caching at every layer of your ASP.NET application. Add cache support to the data layer, business logic layer, UI, or output layer. Memory is now very cheap-so significant performance improvements can be achieved by implementing caching intelligently throughout the application. ASP.NET caching can cover up a lot of fault caching is a way to achieve "good enough" performance without a lot of time and analysis.

Again, memory is now very cheap, so if you can achieve the desired performance by caching output for 30 seconds instead of spending a whole day or even a week trying to optimize your code or database, you will certainly choose a caching solution (assuming you can accept 30 seconds of old data). Caching is one of those features that use 20% of the effort to get an 80% return, so to improve performance, you should first think of ASP.NET caching.

However, if the design is poor, it may end up with adverse consequences, so of course you should also try to design your application correctly. But if you just need to get enough performance immediately, ASP.NET caching is your choice, and you can redesign your application as soon as you have time later. As the simplest form of caching, the page-level output cache simply keeps a copy of the HTML sent in response to the request in memory. Cached output is provided on subsequent requests until the cache expires, so performance is likely to be greatly improved (depending on how much overhead is required to create the original page output-sending cached output is always fast and stable). To implement page output caching, simply add an OutputCache instruction to the page.

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

◆ Duration required attribute. 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, it must be one of the following options: Any, Client, Downstream, None, Server, or ServerAndClient.

◆ VaryByParam required attribute. The names of variables in Request, which should produce separate cache entries. "none" means no change. "*" can be used to create new cache entries for each different array of variables. Variables are separated by ";".

◆ VaryByHeader changes ASP.NET cache entries based on changes in the specified header.

VaryByCustom allows you to specify custom changes in global.asax (for example, "Browser"). You can handle most situations with a combination of the necessary Duration and VaryByParam options. For example, if your product catalog allows users to view catalog pages based on categoryID and page variables, you can cache the product catalog for a period of time with VaryByParam with a parameter value of "categoryID; page" (an hour is acceptable if the product is not changing all the time, so the duration is 3600 seconds). This creates a separate cache entry for each catalog page of each category. Each entry will last for one hour from its * requests. VaryByHeader and VaryByCustom are mainly used to customize the appearance or content of the page according to the client that visits the page. The same URL may need to render output for both browser and mobile phone clients, so different versions of content need to be cached for different clients.

Or, the page may have been optimized for IE, but it needs to be able to completely reduce the optimization for Netscape or Opera (not just destroy the page). The latter example is very common, and we will provide an example that shows how to achieve this goal: example: VaryByCustom is used to support browser customization. In order for each browser to have a separate cache entry, the value of VaryByCustom can be set to "browser". This feature is already built into the cache module and a separate page cache version will be inserted for each browser name and major version.

Fragment caching, it is usually not feasible for a user control to output an ASP.NET cache to cache the entire page, because some parts of the page are customized for the user. However, the rest of the page is common to the entire application. These sections are best suited for caching using fragment caching and user controls. Menus and other layout elements, especially those generated dynamically from the data source, should also be cached in this way. If desired, cached controls can be configured to make changes based on changes to their controls (or other properties) or any other changes supported by the page-level output cache. Hundreds of pages using the same set of controls can also share cache entries for those controls instead of keeping a separate cached version for each page. Implementing fragment caching uses the same syntax as page-level output caching, but applies to user controls (.ascx files) rather than Web forms (.aspx files). In addition to the Location property, user controls also support all the properties that OutputCache supports on Web forms. The user control also supports an OutputCache property called VaryByControl, which changes the ASP.NET cache of the user control (typically a control on a page, such as DropDownList) based on the value of its members.

If VaryByControl is specified, VaryByParam can be omitted. * by default, each user control on each page is cached separately. However, if a user control does not change with the pages in the application and uses the same name on all pages, you can apply the Shared= "true" parameter, which makes the cached version of the user control available to all pages that reference the control. Example

The example caches the user control for 60 seconds and creates a separate cache entry for each change in the query string and for each page on which the control resides.

The example caches the user control for 60 seconds and creates a separate cache entry for each different value of the CategoryDropDownList control and for each page on which the control resides.

*, which caches the user control for 60 seconds in ASP.NET and creates a cache entry for each browser name and major version. The cache entries for each browser will then be shared by all pages that reference the user control (as long as all pages reference the control with the same ID). Page-level and user control-level output caching is indeed a quick and easy way to improve site performance, but the real flexibility and power of ASP.NET caching is provided through Cache objects. Using the Cache object, you can store any serializable data object and control how cached entries expire based on a combination of one or more dependencies. These dependencies can include the elapsed time since the item was cached, the time since the item was last accessed, changes to files and / or folders, and changes to other cached items, and, after a little processing, changes to specific tables in the database.

After reading the above, do you have any further understanding of the suggestions for the use of ASP.NET cache? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.