SharePoint Performance Optimization Best Practices

Avoid site page customization if possible

SharePoint uses page ghosting technique to allow a server farm to scale out to tens of thousands of pages across all the sites within a farm. Page ghosting is valuable because it eliminates the need to transfer the contents of a page definition file from the SQL Server content database to the front-end web server. Page ghosting also makes it possible to process the default page instance for thousands of different sites by using a single page template that is compiled into an assembly DLL and loaded into memory in the IIS worker process just once per web application. This optimization technique is a key factor in the scalability of SharePoint in high-traffic environments running thousands or tens of thousands of sites.

SharePoint comes with different site templates and each template has some default pages templates. These page templates reside on file system of the front-end server. Page templates are used to provision page instances within the context of a site. When a page instance is initially provisioned from a page template, SharePoint doesn't need to store a copy of it in the content database because SharePoint can load the page template from the file system of the Web server and use it to process any request for an uncustomized page instance. Therefore, you can say that page ghosting describes the act of processing a request for an uncustomized page instance by using a page template loaded into memory from the file system of the front-end Web server.

Eliminate Extra Script Files

SharePoint 2010 comes up with rich and very interactive interface to perform different actions. More interactivity also introduces more scripts and code. In my recent SharePoint 2010 internet site project, we got into a situation where we want to eliminate extra scripts for anonymous users. After a little bit of research I found a great solution from Chris O’ Brien for extra script elimination. This solution works great in our scenario. I would recommend reading this great post and getting the benefit from this post.

Blob Caching

This cache can store image, sound, video files, and other large binary files on disk. Disk-based caching is one way in which you can achieve faster processing of content stored in content database. If SharePoint Web application contains large files such as images and multimedia files, enabling disk-based caching improves page delivery time because the cache stores files on the front-end Web server, thus reducing database traffic. Read more

Output Caching

SharePoint uses native ASP.NET caching technology to manage page content serving. It reduces database roundtrips, less CPU time, faster response, shorter latency, etc… SharePoint 2010 adds additional functionality over native ASP.NET output caching called “Cache Profiles”. By using "Cache Profiles" we can control cache behavior based on user’s access rights to a site.

Most of the time output caching is suitable for SharePoint internet sites with anonymous access. Because we might get inconsistent caching behavior. If we’ve more than one web-frontend into our farm. But we can overcome to these inconsistency behavior using SharePoint 2010 cache profiles.

Member Leaks

If you’re custom code for SharePoint applications then make sure you’ve run SPDisposeCheck. This tool may not show all memory leaks in your code. Further investigation is required if you continue to experience issues.

Unnecessary Index Columns

SharePoint index columns are similar to indexing columns in a database table. SharePoint maintains index columns itself instead of SQL Server. Index columns can substantially improve the performance of various query operations, such as queries that use the indexed column, join operations, and ordering operations such as sorting. On the other end, it may cause low performance too. SharePoint stores list items data in "AllUserData" table and for every index column it stores the same value in "NameValuePair" table too. Let’s say, if we’ve 100,000 rows in a list and 3 index columns. It means we’ll have 100,000 rows in "AllUserData" table and 300,000 rows in "NameValuePair" table. So we always try to avoid unnecessary index columns.