Caching Settings

Caching improves the performance of the Lightning Conductor Web Part. Without caching, the content source is queried each time:

• The page loads
• On every page refresh
• Each refresh interval.
  

By default Lightning Conductor Web Part displays the results of the data source query without using the caching mechanism. To enabling caching, select the Enable Caching check box in the Caching Settings section on the Data Source tab.

The first time the Lightning Conductor Web Part is displayed on a page, the resulting content from the data source query is stored in the object cache store associated with the cache engine instance. Subsequently the Web Part displays the content from the cache. From the Instance Name drop down list, you can select the cache instance that the Lightning Conductor Web Part will use. The default instance engine is Global Engine, which is pre-defined. Your SharePoint server administrator can configure additional caching engine instances using the SharePoint Central Administration web site.

Each SharePoint object stored in the cache is tagged with the time it was last retrieved from the SQL Server SharePoint content database. The caching engine first tries the cache store to retrieve the metadata associated with a SharePoint object. If the object is not there or has expired, the caching engine retrieves the object from the SQL Server SharePoint content database. It then stores the updated object in the cache and updates the retrieving time of that object.

There are three cache object expiration strategies based on the configuration of the Expiration Timeout text box, and the two check boxes: Expire on SharePoint Changes and Force Expiration on Timeout:

1. Expiration Timeout only:
   
   The SharePoint object will be fetched from the content database at the interval typed in the Expiration Timeout text box.
   
   
2. Expiration Timeout and Expire on SharePoint Change check box selected:
   
   The cached object is considered as expired when the caching engine detects that this object has been changed in SharePoint content database since the retrieving time of that object. This option is dependant on the use of the SPChange log, which is a setting in the SharePoint Central Administration web site. The caching engine will use strategy based only on timeout for those objects when changes could not be determined using SharePoint change log.
   
   
3. Expiration Timeout and both Expire on SharePoint Change and Force Expiration on Timeout check boxes selected:
   
   The cached object is considered as expired if -
   

• (1) that object has been retrieved more than X minutes ago,
  
  
• (2) or when caching engine detects that this object has been changed in the SharePoint content database since the retrieving time of that object, where X is the value taken from the “Expiration Timeout (Min)” text box.
  

What expiration strategy is best and what value should be specified in “Expiration Timeout (Min)” text box?

There is no common answer to this question for all cases. It depends on the environment in which Lightning Conductor Web Part (LCWP) runs, the user requirements, the sort of items rolled up by LCWP, and so on. However, we can mention several situations for which the answer is precise:

• When items rolled up by LCWP are changed rarely, better performance is to use a strategy based on timeout only and to use large value as expiration timeout, for example, 180 minutes or more.
  
  
• When items rolled up by LCWP are changed often, yet allowance is made for viewing the old states of those items, so long as they are visible for no more than several minutes. In this case it will be better for performance to use a strategy based only on timeout, and to use small value as expiration timeout (e.g. 10 minutes).
  
  
• When it is necessary to see only the current states of the items rolled up by LCWP, then it is required to use strategy based on detecting changes in SharePoint database (with or without forcing expiration on timeout). In this case it is not so important which value will be used as expiration timeout. Using “Force Expiration on Timeout” option could be used in situations when it is required to retrieve cached objects again, even in the situation when such changes will not be detected in SharePoint change log (e.g. in situations when in some reason several kinds of changes has not been logged in SharePoint change log).
  

*Caching Settings where first made available with Lightning Conductor 2010 Web Part v3.0.

Data Source tab →