Share point 2013’s distributed cache service 6.0 (1)

© Hexaware Technologies. All rights reserved. www.hexaware.com© Hexaware Technologies. All rights reserved.

Passionate

Employees

Innovative

Services

Delighted

Customers

Harnessing the Power of

SharePoint 2013’s

Distributed Cache Service

2© Hexaware Technologies. All rights reserved. | www.hexaware.com

What is Distributed Cache?

A distributed cache is an extension of the

traditional concept of cache used in a single

locale.

A distributed cache may span multiple servers so

that it can grow in size and in transactional

capacity.


SharePoint 2013 Distributed Cache

The Distributed Cache (DC) service is built on top of the Windows Server AppFabric Cache.

The Distributed Cache (DC) service provides in-memory caching services to several

features in SharePoint 2013 as listed below

Authentication

Security Trimming

Page load performance

Social Features, Newsfeeds


Architectural Highlights

In SharePoint 2013, it creates session token

during user login for any of the user

authentication method used, either windows

authentication or forms authentication or SAML

token by external identity provider.

Prior to SharePoint 2013, the session token

cache was stored at server-local cache. In

SharePoint 2013, session security tokens are

stored centrally in a Distributed Cache Service’s

Logon Token Cache. This architectural

improvement, made tokens accessible across

the farm, to all WFEs.



User Profile Service Application (UPA) Proxies retrieve configuration details from their

associated UPAs & databases; and cache those details in several per-process in-

memory cache and all such cache information is resident in server memory. Following

Settings are stored in cache

URLs for MySite portals

Following limits

UPA sync configuration (e.g. whether to sync inactive users)

Newsfeed settings

Activity Feed



Prior to SP-2013 ViewState data was stored at the server end, which lead to problem

that subsequent requests would have to be routed to the same server where ViewState

was originally cached. This problem was solved in SP-2013 by storing as key pair value

of GUID and ViewState to distributed ViewState cache.



For user profiles, it enables everything to be

“in sync” and have minimal visible POSTs

back to the server. As the distributed cache

is resident in server memory the browser

have to post back to Distributed Cache

Service. In background data is persisted to

database from the distributed cache to the

database. During post back browser doesn't

have to wait to get data persisted in

database. This drastically improves page

response performance.


Distributed Caching - Installation

SharePoint 2013’s prerequisites installer takes

care of installing the Windows Server AppFabric

and configuring it for cache operations on your

behalf.

There is no initial action required on the part of

administrators to get the Distributed Cache

service installed and operational in their

SharePoint 2013 environment.


Default DC Configuration

Default Memory allocation to DC Service is 10% of total physical memory.

From that it uses half of that memory allocation for data storage i.e. it uses 5% of cache

size.

The other half of that memory allocation is used for memory management overhead.

When the cached data grows, the DC service uses the entire 10% of the allocated

memory.


DC configuration for small farm

Important Note: DC Service has to be turned ON all the WFE servers.

Distributed Cache is

on all WFE Servers


DC configuration for medium farm (10,000+ users)

1. It’s recommended to have dedicated DC Server allocated to the SharePoint

Farm.

2. Use the following method to calculate how much memory can be assigned to

the DC service.

Determine the total physical memory on the server. For this example, we

will use 16 GB as the total physical memory available on the server

Reserve 2 GB of memory for other processes and services that are

running on the cache host. i.e. 16 GB – 2 GB = 14 GB. This remaining

memory is allocated to the Distributed Cache service

Take half of the remaining memory, and convert it to MB. For example,

14 GB/2 = 7 GB or 7000 MB. This is the cache size of the DC service


DC configuration for medium farm (10,000+ users)

APP 03 is made

dedicated Distributed

Cache Server


Wrongly configured DC…

Page render time around 9-10 seconds!!


DC Configured Correctly..

After implementing the Dedicated DC service to a SharePoint farm and correctly updating

the memory allocation the page rendered time improved drastically!

Page render time NOT more than 2 seconds..


DC Configuration - Benefits

As it creates unique session for any of the

user authentication technique like window

authentication or forms authentication or

external identity provider, in a subsequent

calls, it bypasses the need to redirect to

external identity providers and additional

user prompts, in a way avoiding evident

response time delay.

Creation of unique session token and

caching the token avoids the multiple steps

of regeneration of session token and saving

the time to some extent.



Session tokens are centralized cached and

webserver can trace token using windows

identity or session cookie, the user can access

any of the webservers without the need to re-

login.

As ViewState data is stored in Distributed Cache, the problem

related to request routing is resolved and page response time

is improved to a large extent



Social features like URLs for MySite

portals, Following limits, UPA sync

configuration, Newsfeed settings, Activity

Feed are stored in Distributed cache and

configured to Sync all the User Profile

Applications (UPAs). Also during POST

back action, browser have to POST back to

DC and need not wait till data gets

persisted in database. This improved the

page performance drastically.


Challenges & Tips

Following slides covers some of the challenges faced during

real life implementations of Distributed Caching Service in a

medium farm of about 10000 users.

All the tips provided here are actual resolutions provide by our

“Hexaware SharePoint Expert” team


Challenge # 1

You try to interact with the cache service and find that the service is not functioning

correctly.

Tip: Restarting the cluster is a simple first step that will often clear up any issues. Run

the Command Restart-CacheCluster


Challenge # 2

You get an error related to the registry.

Tip: It usually means that the host you are working with is not part of a cluster and it

sneeds to be added.

Run the Add-SPDistributedCacheServiceInstance command to add.


Challenge # 3

You try to add a cache host to the cluster and you get error ”TCP port already in use”


Challenge # 4

You try to remove a cache host from the cluster and you get error “cacheHostInfo is

null”.


Tip for Challenge #3 & #4

Error showed in Challenge#3 & #4 usually means that the server was previously part of a cluster and wasn’t added or removed correctly.

To resolve the issue execute following commands

• $instanceName ="SPDistributedCacheService

Name=AppFabricCachingService"

• $serviceInstance = Get-SPServiceInstance | ?

{($_.service.tostring()) -eq $instanceName –and ($_.server.name)

-eq "<Your Server Name>"}

• $serviceInstance.Delete()

• Add-SPDistributedCacheServiceInstance


Challenge # 5

There was a medium farm with dedicated DC server and was facing page performance

issue. When traced the ULS logs, found following error.

Unexpected error occurred in method 'GetObject' , usage 'Distributed Logon Token Cache'

– Exception crosoft.ApplicationServer.Caching.DataCacheException:

ErrorCode<ERRCA0017>:SubStatus<ES0006>:There is a temporary failure. Please retry

later. (One or more specified cache servers are unavailable, which could be caused by

busy network or servers. For on-premises cache clusters, also verify the following

conditions. Ensure that security permission has been granted for this client account, and

check that the AppFabric Caching Service is allowed through the firewall on all cache hosts.

Also the MaxBufferSize on the server must be greater than or equal to the serialized object

size sent from the client.


Tip for Challenge #5

1. Update default DC parameters

2. Change parameter values for Security Token Service followed by IISRESET on all servers in the.

Set MaxServiceTokenCacfarmheItems to 1500

Set MaxLogonTokenCacheItems to 1500

DC Parameters Default Value Recommended

MaxBufferPoolSize 268435456 1073741824

MaxBufferSize 8388608 33554432

ChannelOpenTimeOut 20 3000

RequestTimeout 20 3000

MaxConnectionsToServer 2 100


Be Aware

“The Distributed Cache service can end up

in a non-functioning or unrecoverable state

if you do not follow the procedures. In

extreme scenarios, you might have to

rebuild the server farm“


Best Thing..

If you set DC Configurations Right then

your SharePoint Farm will have an

advantage of Highest Performance and

Improved Scalability…

Passionate

Employees

Innovative

Services

Delighted

Customers

© Hexaware Technologies. All rights reserved. | www.hexaware.com

Thank you

Technology

Share point 2013’s distributed cache service 6.0 (1)