Cache

When creating new applications or functionality on top of the Verint Community platform, you'll need to consider caching for performance. Rather than using the ASP.net caching object, utilize the Verint Community caching framework so that runtime adjustments can be made without compilation, and you have finer control over where you are caching your items. The Telligent.Evolution.Extensibility.Caching namespace provides an API for adding caching abilities to a Verint Community component.

[toc]

When to use the Verint Community Caching Framework

When you need to create your own custom application and you need finer control over where you are caching your items than is offered by ASP.net caching.

Cache keys and tags

All items in the cache will have an associated key that can be used to identify it. Keys are not case-sensitive and will always be stored in their lowered-case form.

In addition to a key, you can further identify an item by placing one or more tags on it. Like keys, tags are not case-sensitive and will be stored in their lowered-cased form.

Tags are useful when grouping data into logical partitions. Using tags, you can expire a group of items in the same logical partition without knowing all the individual keys. While tags are powerful in this regard, they should never be used in substitution of a good key generating algorithm. Tag operations are very slow in comparison to single key lookups and removals, so be very selective about how and when you use them.

Choosing a cache scope

All cache operations require one or more CacheScope values. When defining a cache layer (see: Caching Overview), each layer will identify what kind of cache it is by using a cache scope.

For example, the built-in ASP.NET cache identifies itself as a Process scope layer because it stores items in locations that are available to all threads running inside the application.

Before caching an item, you'll need to decide what scope(s) to operate in. Here are some general guidelines that you may follow:

 The Telligent cache object comes with built-in providers that are available for use. They include:

• HttpContext (Context scope): Items are cached inside the current HTTP request. This is the fastest cache available for web requests and should always be designed at the lowest level cache in a website environment.

• ASP.NET (Process scope): Items are cached inside the HttpRuntime object. Items cached using this provider are available to all threads that access the same HttpRuntime object. 
  
       NOTE: This cache can be used outside of a web request.

Cache Timeouts

When items are placed into cache, it is not necessary to give a timeout. In these cases, the currently configured default timeout value is used. The out-of-the-box default timeout is 1 minute and 40 seconds.

Many objects in Verint Community use the default timeout value. In addition to a very simple scaling mechanism, controlling the default timeout allows for finer control over the cache system in webfarm scenarios where staleness is a concern. Generally, if more than one server is running a site, the default timeout value should be low to keep staleness at a minimum. The lower the value, the less likely you are to see staleness - but at the cost of decreased cache performance.

Default timeouts are set inside of the caching configuration XML settings. For more information, please see the Configuration documentation.

Cache factors

Cache factors allow us to complete the picture of how long items should be cached. Cache factor values can be set for any cache layer and is used as a universal adjustment on timeout.

Where cache factors become important is when a cache is set up using a distributed cache. For example, assume we have a website that contains many nodes (webfarm). Each node is running the AspNetCache provider to cache items locally on each server. Because we're in a webfarm scenario, we have to reduce our default timeout because we can't risk staleness and other cache inconsistencies.

To increase the cache performance of the website, we want to introduce a distributed cache so longer-lived objects can be held in memory for longer amounts of time. In this situation, we want to increase the default timeout because we know that all web nodes will keep the distributed cache in sync as long as we relay the changes back to the distributed cache server. But this poses a problem: If we increase the default timeout, then the locally cached items in the AspNetCache will risk being stale in any web server that doesn't handle the data operation. But if we do not increase the default timeout, objects will be removed from distributed cache much more frequently than they need to be.

To solve this problem, we can use a cache factor on the distributed layer. By setting a cache factor on the distributed layer, we can keep a lower default timeout for our local server caches. Items sent to distributed cache will be cached longer, by default, then items cached on the local server.

It should be noted that all timeouts are subjected to the factor, not just default timeouts.

Cache factors are set inside of the caching configuration XML settings. For more information, see the Configuration documentation.

Overrides

Included in the Telligent cache system is a mechanism allowing runtime adjustments to be made to cache operations. This allows users to modify values used in Verint Community (or added by a third-party component) if they have a site-specific need to do so. Overrides should be used sparingly, but they offer a level of control that may yield a large benefit.

Before an item is sent to any cache layer, conditions are checked to see if a particular override should be applied. If a condition is met, that override is triggered and no further conditions are processed. This means that only one override can be executed for each cache operation.

Overrides are defined declaratively using XML. For more information on how to set and configure overrides, see the Configuration documentation.

Samples

All of the following examples assume we have this defined (which requires a reference to Telligent.Evolution.Components.dll):

using Telligent.Evolution.Extensibility.Caching.Version1;

Retrieving an item from cache.

var obj = CacheService.Get("key", CacheScope.Context | CacheScope.Process);

Putting an object into cache.

// Get the object from the source.
var obj = GetObjectFromDataSource();

CacheService.Put("key", obj, CacheScope.Context | CacheScope.Process, TimeSpan.FromMinutes(1));

Putting an object into cache using the default timeout.

// Get the object from the source.
var obj = GetObjectFromDataSource();

CacheService.Put("key", obj, CacheScope.Context | CacheScope.Process);

Putting an object into cache using the default timeout and cache tags.

// Get the object from the source.
var obj = GetObjectFromDataSource();

CacheService.Put("key", obj, CacheScope.Context | CacheScope.Process, new string[] { "tag1" });

Removing an item from cache.

CacheService.Remove("key", CacheScope.Context | CacheScope.Process);

RemoveByTags to remove a group of tagged items from cache.

CacheService.RemoveByTags(new string[] { "tag1" }, CacheScope.Context | CacheScope.Process);