SharePoint performance tuning (Page load specifically) has been high on my list for a while, it seems no matter the page load speed, it just never fast enough. Also, customizations can also cripple scalability as many others have found Performance test case study.
Luckily there are companies that provide solutions and Microsoft has also provided some great Technet articles that cover caching and architecture aspects of performance. For this blog I will assume your farm is architecturally sound, if you have customizations they perform well and you would like to shave a few seconds of page load times.
Technet has some great articles that can help you, start with this one “Caching in Office SharePoint“.
BLOB Cache – Binary Large Object cache simply stores retrieved content on the WFE file system. Instead of serving up requests through a SQL call, its done once, cached and served from the WFE file system – Link to more detail. This setting can reduce network traffic backlog to SQL and page content request times. Under certain situations it can reduce performance so be careful.
To enable, edit the web.config on the WFEs add – BlobCache location=”C:\blobCache” path=”\.(gif|jpg|png|css|js|MP4|MP3)$” maxSize=”10″ enabled=”false”
Note that i don’t recommend storing large media such as video and sound in SharePoint instead use a video streaming solution. If your publishing images use a document library so that you can take advantage of browser caching. If you must use MP4 as its the most efficient, don’t use WAV or AVI and the browsers CODEC can handle those file formats very well.
Change SharePoint cache settings to Extranet Publishing Site and also change the custom role provider to use Role Provider Caching. Output Cache – Individual page level. Ideal for heavily accessed Web sites that do not have to frequently present new content. look at your content publishing schedules to determine the best setting. This setting can reduce your page loads to half the time.
ACLs and Caching
If you have enabled the Perform ACL Check output cache profile on a site collection that has more than 10,000 unique Access Control Lists (ACLs), output caching will be disabled for the site collection, and you will receive the following error message “Attempt to release mutex not owned by caller. (Exception from HRESULT: 0x00000120)”. To resolve this issue, download and install the SharePoint Server 2007 Cumulative Update Server Hotfix Package as described in Knowledge Base article 968859 (http://go.microsoft.com/fwlink/?LinkId=156055 ). After installing the April 2009 cumulative update, output caching will still be disabled under the circumstances described above, but no exception will be generated. Object Cache -Individual Web Part control, field control, and content level. Includes cross-list query caching and navigation caching.
If you have versioning enabled on pages this can lead to delays serving pages. To prevent slow page loads as a result of load placed SQL and SharePoint servers. Keep versions to a reasonable number such as 10-15.
From a coding perspective use caching as a mandatory practice – querying a data source on every page load can be resource intensive especially if thousands or sites use the web part in question. One approach would be to use session objects, page output caching, or using the cache object. This article by Steven Smith offers some help. Microsoft Velocity also looking interesting – distributed caching. Also using proper code practices such as Try/Catch and rigorous testing code both performance and functionality.
Network Caching Appliances
WAN Accelerators – I posted a blog about these devices a few years ago when I was doing work with HPs engineering group in Mass. The link to the blog. These tools can reduce page response times and load placed on SharePoint and SQL. Aptimize.com – Aptimize provides an accelerator service for SharePoint. If the caching doesn’t work, have a look at this service www.aptimize.com.
SharePoint will only perform as well as SQL Server is architected and monitored. This include hardware sizing and ongoing maintenance plans for indexing, statistics (DB job run on tables to ensure optimal execution) and optimizing growth (Allocating all space vs. incrementing – an experienced DB with SharePoint experience is a must.
The heart of SharePoint is SQL Server which requires storage that can supply 2 IOPs / GB as a general rule. Designing and ongoing monitoring to ensure storage is performing as require is critical especially in a large shared services / Cloud environment.
More can be found here: