Step 4: Defragment database indexes
SQL Server maintains its own set of indexes for data stored in various databases to improve query efficiency and read operations. Just as with files stored on disk, these indexes can become fragmented. It is important to plan for regular maintenance operations, which includes index defragmentation. Special care should be taken to schedule these types of operations as they are resource-intensive and, in many cases, can prevent data from being written to or read from the indexes.
Step 5: Distribute user data across multiple content databases
Most SharePoint data is stored in lists: tasks, announcements, document libraries, issues, picture libraries, and so forth. A great deal of this data is actually stored in a single table in the content database associated with the site collection. Regardless of how many sites and subsites are created within the SharePoint hierarchy, each site collection has only one associated content database. This means that a site collection with thousands of subsites is storing the bulk of the user data from every list in every site in a single table in SQL.
This can lead to delays as SQL must recursively execute queries over one potentially very large dataset. One way to reduce the workload is to manage the mapping of site collections to content databases. Administrators can use the central administration interface to pre-stage content databases to ensure that site collections are associated with a single database or grouped logically based on size or priority. By adjusting the Maximum Number of Sites setting or changing database status to offline, administrators can also control which content database is used when new site collections are created.
Step 6: Minimize page size
For SharePoint users connected to the portal via a LAN it is easy to manage content and find resources, but for users on the far end of a slower WAN link, the heavyweight nature of a typical SharePoint page can be a real performance-killer.
If you have many remote users, start with a minimal master page, which, as the name implies, removes unnecessary elements and allows designers to start with a clean slate that only contains the base functionality required for the page to render correctly.
Step 7: Configure IIS compression
SharePoint content consists of two primary sources: static files resident in the SharePoint root directories (C:\Program Files\Common Files\Microsoft Shared\12 for 2007 and \14 for 2010) and dynamic data stored in the content. At runtime, SharePoint merges the page contents from both sources then transmits them inside an HTTP response to the requesting user. Internet Information Server (IIS) versions 6 and 7 both contain various mechanisms for reducing the payload of HTTP responses prior to transmitting them across the network. Adjusting these settings can reduce the size of the data transmitted to the client, resulting in shorter load times and faster page rendering.
IIS compression settings can be modified from a base value of 0 (no compression) to a maximum value of 10 (full compression). Adjusting this setting determines how aggressive IIS should be in executing the compression algorithms.