Configuring the Lightning Conductor Web Part Caching Engine

Each Lightning Conductor Web Part can be configured to use a caching mechanism that increases the performance of the Web Part. This is useful when the Lightning Conductor Web Part is aggregating content from a large number of lists and when you want to increase the speed the Web Part rolls up results and displays them in the user’s browser. This minimizes the number of round trips from a Microsoft® SharePoint® 2010 server to the SQL Server® content databases each time the Lightning Conductor Web Part is displayed on a page.

!Enabling caching on a large number of Lightning Conductor Web Parts can result in memory issues on your SharePoint 2010 servers. You need to monitor and plan your LCWP cache settings, together with other SharePoint 2010 caching settings you may have configured. By default the Lightning Conductor Web Part is not configured to cache the results of the rollup queries. Note the LCWP caching mechanism is it’s own caching mechanism, meaning it is not, for example, using the SharePoint object cache mechanism. References to using and monitoring SharePoint 2010 can be found at the end of this page.

The Lightning Conductor Web Part uses a caching engine instance. There is one predefined caching engine instance, Global Engine, which cannot be deleted. Caching engine instances can be configured and additional caching engine instances can be created.

Each time a Lightning Conductor Web Part (LCWP) is added to a page you can configure it to use a LCWP caching engine. A SharePoint server administrator can configure or create LCWP caching engine using the following steps:

1. In the browser, open Microsoft SharePoint 2010 Central Administration web site. On the Quick Launch click System Settings, and then under Farm Management, click Configure Lightning Conductor caching engine.
   
   
   
   The Lightning Conductor Caching Engine Settings page is displayed, which by default displays the settings for the Global Engine caching instance.
   
   
2. If you want to configure a different caching engine instance or create a new caching engine instance, select the down arrow to the right of Global Engine and select Change Engine Instance
   
   
   
   The Select Caching Engine — Webpage Dialog is displayed.
   
   
   
   
3. Click the caching engine instance you wish to configure or in the New Instance Name text box, type the name of the new instance and then click Create New.
   
   
4. Amend the caching settings for each instance as described later on this page.
   
   
5. At the bottom of the LightningTools Caching Engine Settings page, click Save.
   
   
   
   To clear the cache, at the bottom of the LightningTools Caching Engine Settings page, click Invalidate. To delete the caching engine instance click Delete. This option is not displayed for Global Engine.
   

Caching Engine Instances

You only need additional instances of the LCWP caching engine if the caching properties required by the Lightning Conductor Web Part are different. The properties of the LCWP caching engine are described in the following sections. Theoretically each LCWP can use their own instance of the LCWP caching engine, or you can configure several LCWP to use a specific instance of a LCWP caching engine as shown in the following diagram.

For example, you may have added the LCWP multiple time on the same page or on different pages. Some of the Web Parts may be using the caching engine, some of the Web Parts will not. Those Web Parts that are using caching may require the caching engine to handle checked out items, while other part Web Parts do not. In this scenario the only solution is to have two caching engines. The first caching engine should have the Handle Checked Out Items check box selected, and the second caching engine should not have the check box selected. The first set of Web Parts should use the first caching engine and second set of Web Parts should use second caching engine‏. In other words, several instances of the caching engine are required when some of the LCWPs require different caching engine settings than other LCWPs.

Query Running Context

By default when caching is enabled on a Lightning Conductor Web Part, the data source query is run twice in the context of Web Application super user and super reader accounts. Metadata about SharePoint Server objects, such as, SPWeb, SPSite, SPList, etc., are saved in the object cache using these accounts, and then the Access Control List (ACL) of the current user is used to display data from the cache that they have permissions to – security trimmed.

By selecting Use current logged in user context check box, the current user account is used by the data source query and the results of the query are saved in the cache. Each user will have their own copy of the resulting data in cache, which has resource implications. When queries are run in the context of current user context, the settings in the Item Limit Multiplier and Handle Checked Out Items sections are not applicable and will be greyed out.

Web Application Accounts

When the Use current logged in user context check box is not selected then the data source query uses the Web Application super user and super reader accounts, also known as the Portal Super User and Portal Super Reader accounts. It is assumed that the super user account sees all versions of all items, including draft versions, and the super reader account sees only published versions of all items, when the list is configured not to allow readers to see draft versions. The permissions for accounts that you intend to use for the super user and super reader accounts can be configured for each Web Application, using the SharePoint 2010 Central Administration web site or Windows PowerShell, as described in the TechNet article: Configure object cache user accounts in SharePoint Server 2010.

By default, when no value is provided in the Super admin login and the Super reader login text boxes, the caching engine instance will use the site’s System Account as the super user account and “NT AUTHORITY\LOCAL SERVICE” as the super reader account. You can provide accounts for the super user and super reader accounts for each web application, and Microsoft recommends that the account used for the super user and super user accounts are separate accounts.

For the caching engine to work correctly no items should be checked out to the super user and super reader accounts, as when a query that includes these items is made, the checked out version of the item is returned instead of the latest published version. As the site’s System Account is used for other tasks, some items do get checked out to the System Account, therefore Microsoft recommends that you should provide accounts for the super user and super reader accounts and that these two accounts should never be used to login to the site.

*For web applications that use claim based authentication, account names must be provided in required form, for example, the account name of windows user DOMAIN\user must be i:0#.w|DOMAIN\user.

Item Limit Multiplier

On the Configure Rollup Engine Provider step of the Lightning Conductor 2010 Configuration Wizard you may have specified many different data sources and therefore the Web Part may need to execute a SharePoint query against many site collections and sites during the rollup process. In the Multiplier text box in the Item Limit Multiplier section, type an integer value, the default being 3. The multiplier value is used to limit the content return for each SharePoint rollup query.

The value in the Multiplier text box, is only applicable when you type a value for the Lightning Conductor Web Part in the The Limit Amount of Items Return To text box in the Miscellaneous section on the Configure Rollup Engine Provider step.

For each SharePoint query, the LCWP caching engine limits the number of items returned to the number generated by multiplying the value in the Limit Amount of Items Return to text box to the value in the Item Limit Multiplier text box. The caching engine instance executes queries in context of the super admin account and in context of the super reader account, which are then saved in the cache. The Web Part is then able to retrieve the necessary items from the cache for each type of user who displays the page where the Web Part has been added.

Handle Checked Out Items

By default, when Handle Checked Out Items check box is not selected, the latest published items are returned from the data source query, even for users who have checked out the items. When the Handle Checked Out Items check box is selected, the query retrieves the value of checked out items.

Use the SharePoint Change Log

Select the Use Log check box when you want the caching engine instance to detect changes to SharePoint object by using the SharePoint change log. The default is not to use the change log.

Resource Disposing Strategy

Use the two check boxes in this section to specify when the caching engine instance disposes of resources allocated during execution of data source queries:

• Dispose resources allocated during execution of SPSiteDataQuery immediately
• Dispose resources allocated during execution of SPQuery immediately

The default is to reuse the resources allocated during the query, that is, the resources are not released immediately.

Memory Limit

In the Memory Limit text box, type the amount of memory, in megabytes, which can be allocated by the caching engine instance for storing cached objects. The default is to specify no value, that is, there is no memory limit for caching engine instance. When memory limit is exceeded, the caching engine instance will remove some cached objects from the cache in xxx order to free part of allocated memory.

References

• Plan for caching and performance (SharePoint Server 2010) →
• Configure cache settings for a Web application (SharePoint Server 2010) →
• Configure object cache user accounts →
• Monitor cache performance (SharePoint Server 2010) →

← Upgrading the Lightning Conductor Web Part
Testing the installation →