Improve site performance with ASP.net cache

Introduction

Asp. NET provides three main forms of caching: page-level output caching, user control-level output caching (or fragment caching), and caching APIs. The advantage of output caching and fragment caching is that it is very easy to implement, and in most cases it is sufficient to use both types of caching. The caching API provides additional flexibility (which is actually quite a lot of flexibility) and can be used to leverage caching at every level of the application. This paper comprehensively introduces the application of these three kinds of caching techniques in each layer of the system.

Of the many features provided by ASP.net, caching support is certainly the most appreciated feature of mine, and I would say there are good reasons for that. Caching has the greatest potential impact on the performance of an application compared to all other features of ASP.net, and with caching and other mechanisms, asp.net developers can accept the extra overhead of building a site with expensive controls, such as a DataGrid, without having to worry about the impact of performance. To maximize caching in your applications, you should consider ways to implement caching at all program levels.

Steve's Caching Tips

Cache as early as possible;

You should implement caching at every level of your application. 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 prevent many mistakes

Caching is 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 later when you have time.

Page-Level output caching

As the simplest form of caching, the output cache retains only the copy of the HTML that is 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 send cache is always fast and relatively stable).

Realize

To implement the page output cache, simply add a OutputCache directive to the page.

＜%@ 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. Use ";" between variables. are separated.

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 cache the product catalog for a period of time with the VaryByParam parameter value of "Categoryid;page" (if the product is not always changing, an hour is acceptable, Therefore, 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 might have been optimized for IE, which should be canceled for Netscape or opera. The latter example is very common, and we will provide an example that shows how to achieve this goal: