Cache settings operations in SharePoint Server

SharePoint Server provides four types of caches that help improve the speed at which web pages load in the browser:

1. BLOB cache

2. Page output cache

3. Object cache

4. Anonymous search results cache

The BLOB cache is enabled and configured in the Web.config file in the web application to which you want to apply the cache. The page output cache and object cache are usually configured in the user interface at the site collection level. Certain settings for these caches can also be configured at the web application level. The changes that you make to the Web.config file will be applied to all site collections and sites within the web application, and will supersede any configuration made at the site collection level or below.

Note : To use the page output cache or the object cache, you must be using the Publishing feature on your site.

BLOB cache

SharePoint Server provides a disk-based cache that stores files that are used by web pages to help them load quickly in the browser, and reduces the load on the database server when it uses those files. These files are known as binary large objects (BLOBs), and the cache is known as the BLOB cache. The BLOB cache is stored directly on the hard disk drive of a front-end web server computer. The first time that a web page is called, these files are copied from the database to the cache on the server hard disk drive, and all subsequent requests for those files are then served from the hard disk drive cache of the server. By default, the BLOB cache is off and must be enabled to use the functionality it provides. When you enable the BLOB cache on your front-end web server, you reduce the load on the SharePoint Server database server created by read requests from web browsers.

Page output cache profiles

The page output cache stores the rendered output of a page. It also stores different versions of the cached page, based on the permissions of the users who are requesting the page. Page output cache settings can be configured at the site collection level, at the site level, and for page layouts. By default, the page output cache is turned off. The page output cache uses cache profiles that specify how long items should be held in the cache. You can specify different cache profiles to be used for anonymous and authenticated users, which optimizes the use of the cache based on the authentication methods that are allowed on the site. You can configure cache profile settings for a web application by editing the Web.config file on the application server. The cache profile settings that you configure at the web application level will be used for all cache profiles in the site collections for that web application.

Object cache

The object cache reduces the amount of traffic between the web server and the SQL database by storing objects - such as lists and libraries, site settings, and page layouts - in memory on the front-end web server computer. As a result, the pages that require these items can be rendered quickly, increasing the speed with which pages are delivered to the client browser. Object cache settings can be configured at the web application level, and at the site collection level. By default, the object cache is on at the site collection level. You can optimize the object cache for a web application by specifying the size of the object cache. Specifying a larger number can enhance performance for some large sites at the cost of memory on each front-end web server. You can configure other settings for the object cache at site collection level.

Anonymous search results cache

The anonymous search results cache is primarily used by publishing sites that allow access to anonymous users. It saves search results from anonymous users and reuses them for later queries that are the same as the original query. This improves performance on site pages that use the Content Search Web Part.

Configure object cache user accounts in SharePoint Server

The object cache stores properties about items in SharePoint Server. Items in this cache are used by the publishing feature when it renders web pages. The goals of the object cache are to reduce the load on the computer on which SQL Server is running, and to improve request latency and throughput. The object cache makes its queries as one of two out-of-box user accounts: the Portal Super User and the Portal Super Reader. These user accounts must be properly configured to ensure that the object cache works correctly. The Portal Super User account must be an account that has Full Control access to the web application. The Portal Super Reader account must be an account that has Full Read access to the web application.

Note:The Portal Super User and Portal Super Reader accounts must be separate accounts, and they must not be accounts that will ever be used to log in to the site.

In SharePoint Server, querying for items is linked with the user account that makes the query. Various parts of the publishing feature make queries for which the results are cached in the object cache. These results are cached based on the user making the query. To optimize the cache hit rate and memory requirements, the queries must be based on whether a user can see draft items. When a publishing control requests the object cache to make a query to get data for the control, the cache makes the query, not as the user making the request, but instead it makes the query twice: once as the Portal Super User account and once as the Portal Super Reader account. The results of these two queries are stored in the object cache. The results for the Portal Super User account include draft items, and the results for the Portal Super Reader account include only published items. The object cache then checks the access control lists (ACLs) for the user who initiated the request and returns the appropriate results to that user based on whether that user can see draft items. By adding the Portal Super User and Portal Super Reader accounts to the web application, the cache must store results for only two users. This increases the number of results that are returned for a query and decreases the amount of memory that is needed to store the cache.

Note: By default, the Portal Super User account is the site�s System Account, and the Portal Super Reader account is NT Authority\Local Service. There are two main issues with using the out-of-box accounts.

1. The first issue is that some items get checked out to System Account, so when a query that includes these items is made, the checked out version of the item is returned instead of the latest published version. This is a problem because it is not what a user would expect to have returned, so the cache has to make a second query to fetch the correct version of the file. This negatively affects server performance for every request that includes these items. The same problem would occur for any user who has items checked out, if that user�s account was set to be the Portal Super User account. This is why the accounts configured to be the Portal Super User and the Portal Super Reader should not be user accounts that are used to log into the site. This ensures that the user does not inadvertently check items out and cause problems with performance.

2. The default Portal Super Reader account is NT Authority\Local Service, which is not correctly resolved in a claims authentication application. As a result, if the Portal Super Reader account is not explicitly configured for a claims authentication application, browsing to site collections under this application will result in an �Access Denied� error, even for the site administrator. This error will occur on any site that uses any feature that explicitly uses the object cache, such as the SharePoint Server Publishing Infrastructure, metadata navigation, the Content Query Web Part, or navigation.

1. Create the super user account and super reader account

Create 2 normal domain accounts and call them :

domain\superuser

domain\superreader

You can configure the user accounts for the object cache by using Central Administration and Windows PowerShell. You must first create the accounts in the Central Administration website and then add the accounts to the web application by using Windows PowerShell. You must add the user accounts to each web application.

2. To add the user accounts by using Central Administration

The domain\superuser account needs to have a User Policy set for that gives it Full Control to the entire web application. In order to do this you perform the following steps:

1. Go to Central Administration

2. Go to Application Management

3. Go to Manage Web Application

4. Select the web application

5. Click User Policy

6. Add Users

7. Click Next

8. Fill in domain\superuser

9. Select Full Control

10. Click Finish

The domain\superreader account needs to have a User Policy set for that gives it Full Read to the entire web application. In order to do this you perform the following steps:

1. Go to Central Administration

2. Go to Application Management

3. Go to Manage Web Application

4. Select the web application

5. Click User Policy

6. Add Users

7. Click Next

8. Fill in domain\superreader

9. Select Full Read

10. Click Finish

Make note of how the names for the Object Cache Super Reader and Object Cache Super User accounts are displayed in the User Name column. The displayed strings will be different depending on whether you are using claims authentication for the web application.

3. To add the user accounts to the web application by using Windows PowerShell

$w = Get-SPWebApplication "http://<server>/"

$w.Properties["portalsuperuseraccount"] = "domain\superuser"

$w.Properties["portalsuperreaderaccount"] = "domain\superreader"

$w.Update()

If you are using claims based authentication run these cmdlets on one of your SharePoint servers:

$w = Get-SPWebApplication "http://<server>/"

$w.Properties["portalsuperuseraccount"] = "i:0#.w|domain\superuser"

$w.Properties["portalsuperreaderaccount"] = "i:0#.w|domain\superreader"

$w.Update()

Reference