Best practices for capacity management for SharePoint Server 2010

Applies to: SharePoint Server 2010

This article describes the best practices for Microsoft SharePoint Server 2010. For more articles in the Best Practices series, see the Best Practices Resource Center for SharePoint Server 2010 (https://go.microsoft.com/fwlink/p/?LinkID=221383).

For additional information about performance and capacity planning, see the Capacity Management Resource Center for SharePoint Server 2010 (https://go.microsoft.com/fwlink/p/?LinkID=194748).

Best Practices

1. Read the available documentation for information about planning, deploying, testing, monitoring and maintaining your SharePoint Server 2010 deployment.

   • For prescriptive guidance on planning, deploying, testing, monitoring and maintaining SharePoint Server 2010, see Capacity management and sizing for SharePoint Server 2010.

   • For feature-specific capacity management guidance, test results and recommendations, see Performance and capacity test results and recommendations (SharePoint Server 2010).

   • For a list of available technical case studies, see Performance and capacity technical case studies (SharePoint Server 2010).

   • For information about capacity planning and configuration of SQL Server in a SharePoint Server 2010 environment, see Storage and SQL Server capacity planning and configuration (SharePoint Server 2010).

   • Aggressive availability targets can have a major effect on the complexity and scope of the farm topology. For more information, see Plan for availability (SharePoint Server 2010).

   • Global deployments may require special measures to ensure sufficient performance and adoption. For more information, see Global deployment of multiple farms (SharePoint Server 2010).

   • If virtualization will be used to host SharePoint Server 2010 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 Virtualization planning for on-premise or hosted technologies (SharePoint Server 2010).

2. Document your capacity management strategy as early as possible in the planning process, and then refine and update it through the product lifecycle. Implementing early planning and an iterative design process can significantly reduce your risk of discovering that you have underestimated your hardware needs after the deployment has already started.

   Many values in a production deployment will change over the lifecycle of the deployment. Regular review and analysis of SharePoint Server 2010 logs, Internet Information Services (IIS) and Unified Logging Service (ULS) logs, performance counters, and measurements of end user latency on critical sites are necessary to understand the health of the SharePoint Server 2010 deployment, and when it may be necessary to make changes in your topology or add hardware resources.

   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.

   • The geographic location of users and their expected usage characteristics and workloads.

   • For Search, the expected or current index size and the number of content sources, including external content sources such as line-of-business applications.

   • User authentication access methods, the number of user accounts, and document requirements for Profile Synchronization and My Sites.

   • 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.

3. Plan for growth and change, so that your SharePoint Server 2010 environment can continue to deliver an effective business solution.

   Capacity management is an ongoing process, because no implementation remains static with regard to content and usage. Follow the capacity management model to help you validate and tune the initial architecture and to iteratively design and optimize the production environment until it can support design goals with optimal choices of hardware, topology, and configuration.

   Use available monitoring and test tools to validate your environment and to periodically review farm performance against expected results.

   • For more information about the capacity management model, see Capacity management and sizing overview for SharePoint Server 2010.

   • For more information about monitoring SharePoint Server, see Monitoring and maintaining SharePoint Server 2010.

   • The Load Testing Kit (LTK) and SharePoint Diagnostic Studio are tools that are provided in the SharePoint 2010 Administration Toolkit (SharePoint Server 2010). These tools can help you test, analyze, and troubleshoot your environment.

     • For more information about the Load Testing Kit, see Load Testing Kit (SharePoint Server 2010).

     • For more information about the SharePoint Diagnostic Studio (SPDiag 3.0), see SharePoint Diagnostic Studio 2010 (SPDiag 3.0) (SharePoint Server 2010).

4. Carefully plan content database sizes and ensure that your design expectations do not exceed supported limits. Under most circumstances, we recommend that you limit content database sizes to 200 GB to enable fast and reliable backups and to avoid list contention issues during peak usage.

   There are, however, circumstances in which larger content databases are supported. For more information about content database sizing, see the Content Database Limits section of SharePoint Server 2010 capacity management: Software boundaries and limits, and also see Managing Multi-Terabyte Content Databases with Microsoft SharePoint 2010 (https://go.microsoft.com/fwlink/p/?LinkId=228262).

   Also note the following information:

   • Large lists (lists that contain more than 5,000 items) should be carefully planned. For more information about how to plan for large lists, see Designing large lists and maximizing list performance (SharePoint Server 2010) and Estimate performance and capacity requirements for large scale document repositories in SharePoint Server 2010.

   • The time to execute a backup and the probability that it will be reliable are both depend on the storage configuration that is being used for the SharePoint Server 2010 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 you move the site to a production environment, and before you create process definitions. Your environment might require content databases much smaller than 200 GB to ensure timely and reliable backup execution.

5. Document the logical topology as a part of an early design process. SharePoint Server 2010 logical planning documentation should include, at minimum, records of the following information:

   • Farms

   • Service applications

   • Database locations, storage specifications and topology

   • Web applications

   • Content databases

   • Site collections

   • Sites

   • Custom applications

   • Proxy groups

   • 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 SharePoint Server 2010 capacity management: Software boundaries and limits.

   • Before deployment for all these items, consider the following issues:

     • Whether the limits are likely to be exceeded

     • The trigger rules for items that have to be in place for an administrator to detect an over-limit condition

     • The actions that must be taken to resolve the condition

     Note

     Certain limits are affected by other factors which may reduce the effective number of objects, such as site collections, that can be supported by a given web application. Care must be exercised to avoid exceeding supported limits when a container object, such as a content database, contains a large number of other objects.

   • Managing software boundaries is 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.

6. Be familiar with recommended SharePoint Server 2010 scenarios and technical case studies. Compare your application to the following scenarios and case studies, and use them to guide your detailed sizing decisions.

   • Design server farms and topologies (SharePoint Server 2010) contains resources to help you learn about and plan topologies for SharePoint Server 2010.

   • Performance and capacity technical case studies (SharePoint Server 2010) contains a list of case studies for existing SharePoint Server 2010 production environments.

   • Performance and capacity test results and recommendations (SharePoint Server 2010) contains a list of feature-specific test results and related performance and capacity recommendations.

7. Plan your monitoring strategy by identifying 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 SharePoint Server 2010 capacity management: Software boundaries and limits and Managing Multi-Terabyte Content Databases with Microsoft SharePoint 2010 (https://go.microsoft.com/fwlink/p/?LinkId=228262).

8. Optimize your applications. In general, the optimization of applications will provide more long-term benefits (including faster performance and reduced load on the server) than the addition of hardware to the farm with no further optimizations. 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:

   • Checklist for Testing SharePoint Web Parts (https://go.microsoft.com/fwlink/p/?LinkId=135710)

   • Using the Developer Dashboard (https://go.microsoft.com/fwlink/p/?LinkId=199580)

   • Team Foundation Server Resource Center (https://go.microsoft.com/fwlink/p/?LinkId=135712)

   • Plan for sites and solutions (SharePoint Server 2010)

9. Stress test your environment before deploying it to 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.

   Use available test tools to validate your environment and to periodically review farm performance against expected results. The Load Testing Kit (LTK) and SharePoint Diagnostic Studio are tools that are provided in the SharePoint 2010 Administration Toolkit (SharePoint Server 2010). These tools can help you test, analyze and troubleshoot your environment.

   For more information about the Load Testing Kit, see Load Testing Kit (SharePoint Server 2010).

   For more information about the SharePoint Diagnostic Studio (SPDiag 3.0), see SharePoint Diagnostic Studio 2010 (SPDiag 3.0) (SharePoint Server 2010).