Understanding Scalability for SharePoint

The first step in scaling a SharePoint environment is to understand the level of usage it will receive, both presently and in the future. After the level of usage is determined, understanding which specific components can be extended is vital to structuring the system to match the desired user load. The key is to match SharePoint functionality to the specific identified need.

Mapping SharePoint Functionality to Business Needs

When deploying SharePoint, the primary concern in regards to scalability is how many users will utilize the system. For departmental collaboration, the numbers may be small. For large, publicly accessible portals, on the other hand, the numbers could scale up quickly. Scaling a SharePoint implementation based on the number of users is simplistic but can be used as a starting point. In addition to total number of users, the following factors should be identified to more fully understand the load placed on a SharePoint server:

• Number of users

• Pages per user per work day

• Length of work day (hours)

• Type of work performed and level of Office integration

• Size of document repositories

Collecting this information and understanding who will be accessing a SharePoint environment is the first step toward properly scaling the environment.

Planning for Capacity with SharePoint

When designing a SharePoint environment, it is always best to start the design simply and then expand on that design as needs arise. With SharePoint, this means that a single server should be planned and then other servers added as new constraints are identified. There are several general limits that a single server should not exceed in SharePoint, and those limits should be understood. These limits are as follows:

• Number of SharePoint users less than 2,000 The number of specifically defined users in a SharePoint site should not exceed 2,000, or runs the risk of performance degradation. If more users are needed, Active Directory group membership can be used to scale the number of users to the tens of thousands.

• Site collections of less than 50,000 Each site collection should hold no more than 50,000 users for optimal performance.

• Subsites to a website less than 2,000 More than 2,000 subsites of any one site slows server performance.

• Documents in a single folder of a document library less than 2,000 Performance degrades if more than 2,000 documents are stored in a single folder. Using multiple folders, however, increases this limit to almost 2 million documents.

• Items in a list less than 2,000 Any more than this slows access to the individual list.

• Less than 100 Web Parts per page Loading more than 100 Web Parts slows down the users' ability to view a page.

• Individual document size less than 50MB The bigger a document grows, the greater strain the document has on an environment. The default "hard limit" in SharePoint is 50MB; any larger documents would seriously slow down the server.

Understanding these limits is an important part of scaling the environment. If, after designing and implementing a SharePoint environment, any of these limits is reached, SharePoint should be scaled to match.

Gauging Content Growth

In addition to the amount of data that initially is loaded into SharePoint, an understanding of how fast that content will grow is critical toward properly scaling an environment. Running out of storage space a year into a SharePoint deployment is not an ideal situation. It is important to understand how quickly content can grow and how to control this inevitable growth.

Proper use of site quotas in SharePoint is an effective way to maintain control over the size that a SharePoint database can grow to. Implementing site quotas as they are created is a recommended best-practice approach and should be considered in most situations. It is easy to bloat SharePoint with unnecessary data, and site quotas help local site administrators to make judicious use of their available space.

SharePoint's SQL database can grow in size dramatically, depending on how heavily it is used and what type of content is included in it. Table 22.1 illustrates the effect that various data sources can have on a SQL database. Of particular note is the search and indexed content, which can grow large in tandem with the existing content.

Table 22.1. Effect of Various Components on SQL Server

Storage Type	Size
Database overhead	12MB
WSS site overhead	4MB
Document metadata (10 properties)	12KB
Search content	Up to 25% of content size
Indexed content	Up to 50% of content size
Transaction log	24% of content size on average after initial content upload

After SharePoint is implemented, it is important to monitor the system to ensure that it is not growing too fast for its own good. In addition to some of the default alerts and tools, a Management Pack for Microsoft Operations Manager (MOM) has been specifically designed to collect information about SharePoint, including the ability to monitor growth of specific components.