Analysis and practice examples of the ASP.NET caching method
- 2020-05-10 17:59:48
- OfStack
Add caching support to the data layer, business logic layer, UI, or output layer. Memory is now very cheap -- so you can get a big performance boost by implementing caching across your application in a smart way. Caching is a way to get "good enough" performance without a lot of time and analysis.
Again, memory is now very cheap, so if you can get the desired performance by caching the output for 30 seconds instead of trying to optimize the code or the database for a full day or even a week, you will definitely choose the caching solution (assuming you can accept 30 seconds of old data). Caching is just one of those features that gets 80% for 20% effort, so to improve performance, think of caching first.
However, if the design is bad, it can end up having bad consequences, so you should certainly try to design the application correctly. But if you just need to get high enough performance right away, caching is your best bet, and you can redesign the application as soon as you have time. The page-level output cache is the simplest form of caching, and the output cache simply keeps in memory a copy of HTML sent in response to a request. The cached output is provided on subsequent requests until the cache expires, which can result in a significant performance improvement (depending on how much overhead is required to create the raw page output and send the cached output is always fast and stable). To implement page output caching, simply add an OutputCache directive to the page.
Like other page directives 1, this directive should appear at the top of the ASPX page, before any output. It supports five properties (or parameters), two of which are required. Duration required properties. The amount of time a page should be cached in seconds. It has to be a positive integer. Location specifies where the output should be cached. To specify this parameter, it must be one of the following options: Any, Client, Downstream, None, Server, or ServerAndClient. VaryByParam required properties. The names of the variables in Request, which should generate separate cache entries. "none" means no change. *" can be used to create a new cache entry for each different array of variables. Between variables, "; "Separate. VaryByHeader changes the cache entry based on changes in the specified header.
VaryByCustom allows you to specify custom changes in global.asax (for example, "Browser"). Most cases can be handled with a combination of the required Duration and VaryByParam options. For example, if your product catalog allows users to view the catalog pages based on categoryID and page variables, you can use the parameter value "categoryID; page's VaryByParam caches the product catalog for a period of time (1 hour is acceptable if the product is not changing all the time, so the duration is 3600 seconds). This will create a separate cache entry for each category for each directory page. Each entry will last for an hour from its first request. VaryByHeader and VaryByCustom are primarily used to customize the appearance or content of a page based on the client that is accessing it. The same URL may need to render output for both browser and mobile phone clients, so different content versions need to be cached for different clients.
Alternatively, the page may have been optimized for IE, but it needs to be completely optimized for Netscape or Opera (rather than just breaking the page). Example: VaryByCustom is used to support browser customizations. To enable each browser to have a separate cache entry, the value of VaryByCustom can be set to "browser". This functionality is already built into the caching module and will be inserted into a separate page cache version for each browser name and major version.
Fragment caching, user control output caching caching entire pages is usually not feasible 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 dynamically generated from data sources, should also be cached in this way. If needed, the cached controls can be configured to change 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 the cached entries for those controls, rather than keeping a separate cached version for each page. The syntax used to implement fragment caching is similar to page-level output caching, but applies to user controls (.ascx files) rather than Web forms (.aspx files). In addition to the Location properties, user controls also support all the properties that OutputCache supports on the Web form. The user control also supports an OutputCache property called VaryByControl, which changes the control's cache based on the value of the member of the user control (usually a control on the page, for example, DropDownList).
If VaryByControl is specified, VaryByParam can be omitted. Finally, 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, the Shared="true" parameter can be applied, which makes the cached version of the user control available to all pages that reference the control. The sample
The example caches the user control ASP.NET for 60 seconds and creates a separate cache entry for each change in the query string, for each page on which the control resides.
The example caches the user control ASP.NET for 60 seconds and creates a separate cached entry for each different value of the CategoryDropDownList control for each page on which the control resides.
Finally, the example caches the ASP.NET user control for 60 seconds and creates one cache entry for each browser name and major version. Each browser's cache entry is then Shared by all the pages that reference the user control (as long as all the pages reference the control with the same ID). Page-level and user-control-level output caching is certainly a quick and easy way to improve site performance, but the real flexibility and power of the ASP.NET cache is provided through Cache objects. With the Cache object, you can store any serializable data object, controlling how the cache entry expires based on a combination of one or more dependencies. These dependencies can include time elapsed since the item was cached, time elapsed since the item was last accessed, changes to files and/or folders, changes to other cached items, and, after some minor processing, changes to specific tables in the database.
Again, memory is now very cheap, so if you can get the desired performance by caching the output for 30 seconds instead of trying to optimize the code or the database for a full day or even a week, you will definitely choose the caching solution (assuming you can accept 30 seconds of old data). Caching is just one of those features that gets 80% for 20% effort, so to improve performance, think of caching first.
However, if the design is bad, it can end up having bad consequences, so you should certainly try to design the application correctly. But if you just need to get high enough performance right away, caching is your best bet, and you can redesign the application as soon as you have time. The page-level output cache is the simplest form of caching, and the output cache simply keeps in memory a copy of HTML sent in response to a request. The cached output is provided on subsequent requests until the cache expires, which can result in a significant performance improvement (depending on how much overhead is required to create the raw page output and send the cached output is always fast and stable). To implement page output caching, simply add an OutputCache directive to the page.
<%@ OutputCache Duration="60 " VaryByParam="*" %>
Like other page directives 1, this directive should appear at the top of the ASPX page, before any output. It supports five properties (or parameters), two of which are required. Duration required properties. The amount of time a page should be cached in seconds. It has to be a positive integer. Location specifies where the output should be cached. To specify this parameter, it must be one of the following options: Any, Client, Downstream, None, Server, or ServerAndClient. VaryByParam required properties. The names of the variables in Request, which should generate separate cache entries. "none" means no change. *" can be used to create a new cache entry for each different array of variables. Between variables, "; "Separate. VaryByHeader changes the cache entry based on changes in the specified header.
VaryByCustom allows you to specify custom changes in global.asax (for example, "Browser"). Most cases can be handled with a combination of the required Duration and VaryByParam options. For example, if your product catalog allows users to view the catalog pages based on categoryID and page variables, you can use the parameter value "categoryID; page's VaryByParam caches the product catalog for a period of time (1 hour is acceptable if the product is not changing all the time, so the duration is 3600 seconds). This will create a separate cache entry for each category for each directory page. Each entry will last for an hour from its first request. VaryByHeader and VaryByCustom are primarily used to customize the appearance or content of a page based on the client that is accessing it. The same URL may need to render output for both browser and mobile phone clients, so different content versions need to be cached for different clients.
Alternatively, the page may have been optimized for IE, but it needs to be completely optimized for Netscape or Opera (rather than just breaking the page). Example: VaryByCustom is used to support browser customizations. To enable each browser to have a separate cache entry, the value of VaryByCustom can be set to "browser". This functionality is already built into the caching module and will be inserted into a separate page cache version for each browser name and major version.
<%@ OutputCache Duration="60 " VaryByParam="None" VaryByCustom="browser" %>
Fragment caching, user control output caching caching entire pages is usually not feasible 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 dynamically generated from data sources, should also be cached in this way. If needed, the cached controls can be configured to change 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 the cached entries for those controls, rather than keeping a separate cached version for each page. The syntax used to implement fragment caching is similar to page-level output caching, but applies to user controls (.ascx files) rather than Web forms (.aspx files). In addition to the Location properties, user controls also support all the properties that OutputCache supports on the Web form. The user control also supports an OutputCache property called VaryByControl, which changes the control's cache based on the value of the member of the user control (usually a control on the page, for example, DropDownList).
If VaryByControl is specified, VaryByParam can be omitted. Finally, 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, the Shared="true" parameter can be applied, which makes the cached version of the user control available to all pages that reference the control. The sample
<%@ OutputCache Duration="60 " VaryByParam="*" %>
The example caches the user control ASP.NET for 60 seconds and creates a separate cache entry for each change in the query string, for each page on which the control resides.
<%@ OutputCache Duration="60 " VaryByParam="none" VaryByControl="CategoryDropDownList" %>
The example caches the user control ASP.NET for 60 seconds and creates a separate cached entry for each different value of the CategoryDropDownList control for each page on which the control resides.
<%@ OutputCache Duration="60 " VaryByParam="none" VaryByCustom="browser" Shared="true %>
Finally, the example caches the ASP.NET user control for 60 seconds and creates one cache entry for each browser name and major version. Each browser's cache entry is then Shared by all the pages that reference the user control (as long as all the pages reference the control with the same ID). Page-level and user-control-level output caching is certainly a quick and easy way to improve site performance, but the real flexibility and power of the ASP.NET cache is provided through Cache objects. With the Cache object, you can store any serializable data object, controlling how the cache entry expires based on a combination of one or more dependencies. These dependencies can include time elapsed since the item was cached, time elapsed since the item was last accessed, changes to files and/or folders, changes to other cached items, and, after some minor processing, changes to specific tables in the database.