Updated Best Practices for SharePoint capacity management documentation on TechNet
Thinks
Recently (12/04/2008) updated guidance on proven practices (a.k.a. Best Practices) for capacity management for SharePoint implementations on TechNet.
Highlights (well almost the complete post from TechNet link with highlights added for emphasis)
Document your capacity planning strategy as early as possible in the planning process, and then refine it as the project continues. Early planning can significantly reduce your risk of discovering that you have underestimated your hardware needs after the deployment has already started.
Document information in the following areas:
The number of users, requests per second (RPS), number of sites, number of documents, and the amount of data that is stored are important numbers to record.
For Search, document the number of content sources and the index size.
Document user authentication access methods and numbers.
Values that will change over time have to be projected in this manner — usually on a yearly basis.
Some projects will also have extensive or complex migration requirements for data and applications, and may contain complex integration or customization code. Estimate the number of customized sites and the location and migration requirements for custom code and data.
Aggressive availability targets can have a major effect on the complexity and scope of the farm topology. For more information, see Plan for redundancy (Office SharePoint Server).
Global deployments may require special measures to ensure sufficient performance and adoption. For more information, see Globally deploying multiple farms.
If virtualization will be used to host Office SharePoint Server computers, research the effect that virtualization will have on sizing. Although virtualization can provide many benefits, it is important to understand how it may affect memory and processor utilization, the performance and capacity of shared disks, and several other key factors. For more information, see Performance and capacity requirements for Hyper-V.
The previous information will help you determine the number of farms required and their optimal topologies (small, medium, and large).
Capacity planning should be revisited repeatedly in all phases of a project as assumptions become more concrete and more detailed hardware and configuration decisions have to be made. Plan accordingly.
Approximate rapid capacity planning can be conducted early in the process by using well-known guidelines, but be aware that rough estimations should not be considered a replacement for detailed sizing later in the project. These assumptions should be examined for their applicability to your deployment.
Well-known guidelines include the following:
1,000 users yield one RPS Note that this guideline applies to a typical user at 10 percent concurrency. For more information, see Estimate performance and capacity requirements for Windows SharePoint Services collaboration environments (Office SharePoint Server).
Plan for a maximum of 20,000 users per collaboration Web server This guideline follows from the previous guideline and from the Windows SharePoint Services 3.0 collaboration benchmark that is documented in Estimate performance and capacity requirements for Windows SharePoint Services collaboration environments (Office SharePoint Server).
Deploy four or five Web servers per collaboration farm In general, collaboration farm deployments are most efficient when four or five Web servers are used. For more information, see the collaboration benchmark that is documented in Estimate performance and capacity requirements for Windows SharePoint Services collaboration environments (Office SharePoint Server).
Use a separate instance of SQL Server for each 5 terabytes of content Experience shows that database performance starts to decline when more than 50 content databases of 100 GB each are deployed.
Keep content database sizes under 100 GB to enable fast and reliable backups, and to avoid list contention issues during peak usage. Also note the following:
The use of large lists (lists that contain more than 2,000 items) should be carefully planned. For more information about how to plan for large lists, see White paper: Working with large lists in Office SharePoint Server 2007.
The time to execute a backup and the probability that it will be reliable are both very dependent on the storage configuration that is being used for the Office SharePoint Server databases.
Measure the time that is required to execute and the reliability of the backup-and-restore process for realistically sized data sets in a lab before the site is moved to a production environment, and before you create process definitions. Your environment might require content databases much smaller than 100 GB to ensure timely and reliable backup execution.
SharePoint logical planning documentation should include, at minimum, records of the following information:
Farms
Web applications
Content databases
Site collections
Sites
Custom applications
Managed paths
URLs
Authentication and authorization
For each of these items, be aware of the following considerations:
All the previous items have limits that must be respected. Limits and software boundaries are documented in Plan for software boundaries (Office SharePoint Server).
For all these items, consider before deployment whether the limits are likely to be exceeded, which items trigger rules that have to be in place for an administrator to detect an over-limit condition, and which actions must be taken to resolve the condition.
Managing software boundaries is usually an iterative process. Respecting all the relevant boundaries for a large installation can be difficult and may require splitting a farm into two separate farms. Make sure that you allow for enough time and effort to complete the planning for this phase.
Be aware that the use of SharePoint groups or Active Directory groups to manage users may affect capacity and performance. Before you use SharePoint groups or Active Directory, make sure that you understand the consequences for your farm as it is configured.
Be familiar with the tested Office SharePoint Server scenarios. Compare your application to the following scenarios and use them to guide your detailed sizing decisions:
Collaboration Plan for performance and capacity (Windows SharePoint Services)
Portal collaboration Estimate performance and capacity requirements for portal collaboration environments
Publishing Estimate performance and capacity requirements for Internet environments (Office SharePoint Server)
Search Estimate performance and capacity requirements for search environments
Excel Services Estimate performance and capacity requirements for Excel Services environments
InfoPath Forms Services Estimate performance and capacity requirements for InfoPath Forms Services environments (Office SharePoint Server)
Workflow applications Performance Characteristics of Windows Workflow Foundation (https://go.microsoft.com/fwlink/?LinkId=135708\&clcid=0x409)
Enterprise content management Plan enterprise content storage
Use 64-bit server versions wherever possible to enable scale-up scenarios and improve performance. For more information about why you should use 64-bit hardware and software, see the following article: 64-Bit and the Admin Toolkit Download Trend (https://go.microsoft.com/fwlink/?LinkId=135709\&clcid=0x409). Future versions of Office SharePoint Server will only support 64-bit hardware and operating systems.
Plan the monitoring rules that you will use to trigger the appropriate scale-out and scale-up options. Also, plan the processes that those triggers start. The following are some of the more important triggers:
A content database reaches its limit.
The recommended maximum site count in a site collection is reached.
The recommended maximum site collection count in a content database is reached.
Other limits can be found in Plan for software boundaries (Office SharePoint Server) and Planning and Monitoring SQL Server Storage for Office SharePoint Server: Performance Recommendations and Best Practices (white paper).
In general, the optimization of applications will provide more long-term benefits (including faster performance and less load on the server) than only the addition of hardware to the farm. Make sure that there is governance in place to ensure that the customizations and applications that are deployed meet minimum standards for performance and resource utilization.
For more information about testing and optimizing customizations, see the following articles:
Be sure to stress test customized platforms before they go into production. Even if exact user behavior is difficult to predict and simulate before deployment, stress testing provides the following benefits:
Customization performance issues can be identified and addressed.
Customization quality issues can be uncovered before they affect farm users.
The mitigation of issues immediately following deployment leads to more rapid and successful adoption, which ultimately improves the return on investment for the deployment.
Links
Clinks
- Best thing to do is review the complete article on TechNet. I have tried to add emphasis on items that I have see creep up over time.