Caching technology and its application in Rainbow Portal

Cache

　　1. ASP. NET Caching Technology Overview

Caching data from a database to memory (or to other sites) eliminates the need to access the database when each page is requested. Because the speed of returning data from memory is always faster than the newly supplied data, the performance of the application can be greatly improved.

Asp. NET provides you with the most flexibility to use caching techniques, you can cache entire HTML pages, or portions of HTML pages, or objects. You can set an expiration policy, or set dependencies that automatically move out of the cache when other resources, such as files or database tables, change.

Asp. NET, there are two basic types of caching:

Output caching

Page output caching is the simplest caching mechanism that saves the entire ASP.net page content in server memory. When the user requests the page, the system outputs the relevant data from memory until the cached data expires. In this process, the cached content is sent directly to the user without having to go through the page process lifecycle again. Typically, page output caching is especially useful for pages that contain content that does not need to be modified frequently, but that requires a lot of processing to compile. It is important to note that the page output cache saves the entire contents of the page in memory and is used to complete the client request.

You can use it in a set of asp.net pages by configuring the cache policy in Web.config. You can also set the page cache by HttpCachePolicy class programming.

Data caching

Application data caching provides a programmatic way to store arbitrary data in memory through key/value pairs. Using application caching is similar to using application state. However, unlike application state, the data in the application data cache is volatile, meaning that the data is not stored in memory throughout the application life cycle. The advantage of the application data cache is that the asp.net manages the cache, which removes items from the cache when items expire, is invalid, or is out of memory, and can configure application caching to notify the application when an item is removed.

There are also two special caches, based on the above caching model:

Partial caching

Partial caching is essentially an output cache. As the name suggests, a partial cache of pages stores part of the page in memory in response to user requests, while other parts of the page are dynamic content. The implementation of page partial caching includes two ways: control caching and replace-behind caching. The former is also known as fragment caching, which allows you to cache portions of the page's output by allowing information that needs to be cached to be contained within a user control, and then marking the user control as cacheable. This approach caches specific content on the page without caching the entire page, so you'll need to re-create the entire page each time. For example, if you want to create a page that displays a large number of dynamic content (such as stock information), some of which are static content (such as weekly summaries), you can place the static part in the user control and allow caching of the content. The cache replacement is exactly the opposite of the control cache. This way the entire page is cached, but the sections in the page are dynamic. For example, if you want to create a page that is static for a specified period of time, you can set the entire page to be cached. If you add a Label control that displays a user name to a page, the contents of the label remain unchanged for each page refresh and for each user, always displaying the name of the user who requested the page before caching the page. After using the cache replacement mechanism, you can configure the page to be cached and to mark individual portions of the page as not cacheable. In this case, you can add a label control to the non-cached part so that the controls are dynamically created for each user and for each page request.

Data source Caching

Data source caching is the caching of data in a data source control such as SqlDataSource, ObjectDataSource, and XmlDataSource, which is actually a data cache, except that the cache is implemented internally by the control.

Cache dependencies

Cache dependencies allow cached items to depend on another resource, so that when a resource changes, the cache entry is automatically removed.

Asp. NET includes 3 types of dependencies

Dependent on other cache entries

dependent on a file or folder

Depends on the database query.

Alternatively, you can use aggregation dependencies, or custom cache dependencies.

Caching also has its own drawbacks. For example, the displayed content may not be the most recent and accurate, so you must set up an appropriate caching policy. Caching increases the complexity of the system and makes it difficult to test and debug, as you set breakpoints, monitoring variables, and so on, because the cache may not be valid for debugging.

　　2. Data caching in the Rainbow portal

Rainbow Portal Portal, page, module configuration information, page layout, theme and other information are all saved to the database, if every time from the data library read, will affect performance. Rainbow has used data caching techniques from this process.

Two auxiliary classes:

Rainbow.Framework.Settings.Cache.Key realizes the cache key name acquisition, its method is static. Since rainbow A Web site can contain multiple portals, each portal has a separate setting, so the cached key name distinguishes between the portal. The key class is prefixed with the alias of the portal for each key name.

For example, get the key name for portal configuration information:

public static string Portalsettings ()
{
return string. Concat (Portal.uniqueid, "_portalsettings");
}
The Rainbow.Framework.Settings.Cache.CurrentCache class encapsulates the operation of the current cache.
Rainbow.Framework.Site.Configuration namespaces in the Portalsettings class, PageSettings class, Modulesettings class; The LayoutManager class in the Rainbow.Framework.Design namespace, Thememanager class, etc., all apply caching technology. The general process is: first to determine the current cache has no cached value, if there is a direct read from the cache, if not from the database read, and then saved to the current cache.
Take the Portalsettings class as an example to illustrate:
public class Portalsettings
{
......
public static Hashtable getportalbasesettings (String portalpath)
{
Hashtable _basesettings;
if (! Currentcache.exists (Key.portalbasesettings ()))
{
Read from the database
......
Save to cache
CacheDependency settingdependencies =
New CacheDependency (
New string[]
{
Layoutmanager.path,
Layoutmanager.portallayoutpath,
Thememanager.path,
Thememanager.portalthemepath
});
using (settingdependencies)
{
Currentcache.insert (Key.portalbasesettings (), _basesettings, settingdependencies);
}
}
Else
{
_basesettings = (Hashtable) currentcache.get (Key.portalbasesettings ());
}
return _basesettings;
}
For cache removal issues, Rainbow on the one hand, the use of cache-dependent automatic removal, such as the settingdependencies in the above code, on the other hand explicitly removed in the program, such as in the Portalsettings class, when the Portal configuration changes, To remove the cache:

public static void updateportalsetting (int portalid, string key, String value)
{
Update
....
Currentcache.remove (Key.portalsettings ());
Some of the modules in the Rainbow portal also use caching techniques, but there are some problems, such as the use of data caching in the Whosloggedon module, However, the cache key name is not obtained through the Rainbow.Framework.Settings.Cache.Key class, so that when there are multiple portal sites in a site, the statistics of the site will appear incorrectly.