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.
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.
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.
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:
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.