• What's New in 3.4 SP1?
• Features
•  
• Externalize BLOBs
• Caching SharePoint Data
• Multi-Tier Storage
• Minify JavaScript
• ViewState Caching
•  
• StorageEdge ROI Calculator
•  
• StorageEdge Blogs
• Technical Whitepapers
• Related Articles
• Product Videos
•  
• StorageEdge Forum
•  

Caching SharePoint Data

StorageEdge lets you cache list data, BLOBs, and ASP.NET Session State to help you boost performance and scalability of SharePoint. Performance improvement comes because an in-memory cache is much faster than making expensive database trips over and over again. And, scalability comes because traffic to the database is reduced considerably and allows the database to handle more concurrent users.

Why Cache List Data?

Lists in SharePoint represent most of the structured data that the user sees. And, this list data is stored in SQL Server database. So, if you cache list data in an in-memory cache, you can access it much faster than going to the database. And, by reducing database trips, you’re no longer going to see the database becoming a scalability bottleneck when you increase the number of users. Here are some things you can do with list caching.

• Keep list data fresh in the cache through expirations
• Keep list data cache synchronized across all WFE servers in the farm
• Use InProc/OutProc client cache along with a distributed cache
• Mange all list caching from a centralized web based admin app
• Monitor list cache activities in PerfMon

Why Cache BLOBs?

StorageEdge lets you externalize BLOBs to relieve pressure on the SQL Server database. Additionally, StorageEdge lets you cache frequently used BLOBs on WFE servers in an InProc/OutProc client cache to give your SharePoint app further boost and reduce traffic even to the external BLOB storage. This in-memory client cache is much faster than the disk based BLOB cache that SharePoint provides you. Here are some things you can do with BLOB caching.

• Keep a subset of BLOBs in client cache on WFE servers
• Specify max cache size and evict some BLOBs when cache is full
• Keep BLOBs fresh by expiring them in the cache
• Keep cache light by removing unreferenced BLOBs from cache
• Manage all BLOB caching from a centralized web based admin app
• Monitor BLOB cache activity in PerfMon

Why Store ASP.NET Session State in Cache?

A number of SharePoint features use ASP.NET Session state. This includes Forms Services, Project Server, and any custom applications and web parts you develop in SharePoint. However, by default, SharePoint stores Session State in SQL Server but that is not the best place to keep your sessions. Here are some reasons why you should store SharePoint Session State in a distributed cache rather than in SQL Server:

• In-memory distributed cache much faster to access than SQL Server
• Distributed cache replicates sessions to multiple servers
• Add or remove cache servers at runtime without stopping the app
• Plug-in distributed cache storage through web.config as an SSP
• Monitor Session State cache activity in PerfMon

Below is a diagram showing how caching fits into a typical SharePoint application. Please note that you don’t have to create a separate caching tier and can host the cache on your WFE servers. Separate caching tier is recommended (but not required) if you have 4 or more WFE servers.