Any enterprise platform needs to be able to adjust, grow, and scale out to fit the needs of a changing organization. SharePoint is no exception to this rule, and the creators focused on the ability to scale certain components within SharePoint to be able to adjust to the unique conditions that exist in various environments. For small organizations in need of simply document management and team sharing, Windows SharePoint Services (WSS) offers a rich set of easily deployed capabilities. For larger or growing organizations, the full Microsoft Office SharePoint Server product allows for the centralization of information and the distribution of knowledge.
This chapter focuses on techniques and information necessary to scale a SharePoint implementation to organizations of varying sizes. Specific components that can be scaled are described and contrasted. High-redundancy options such as clustering and Network Load Balancing for SharePoint and SharePoint's SQL Databases are outlined. In addition, examples of scalability in organizations of different sizes are presented.
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 other servers added as new constraints are identified. A single server should not exceed several general limits in SharePoint, and those limits should be understood. These limits are as follows:
Number of SharePoint users fewer than 2,000—The number of specifically defined users in a SharePoint site should not exceed 2,000, or the risk of performance degradation arises. 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 fewer than 50,000—Each site collection should hold no more than 50,000 users for optimal performance.
Subsites to a website fewer than 2,000—More than 2,000 subsites of any one site slows server performance.
Documents in a single folder of a document library fewer than 10,000—Performance degrades if more than 10,000 documents are stored in a single folder. Using multiple folders, however, increases this limit to almost two million documents.
Items in a view fewer than 2,000—Any more than this slows access.
Fewer 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 that document has on an environment. The default "hard limit" in SharePoint is 50MB; any larger documents would seriously slow down the server. The maximum document size is 2GB.
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.