Partager via

Best practices for capacity management for SharePoint Server 2010

  • Article

 

S’applique à : SharePoint Server 2010

Dernière rubrique modifiée : 2016-11-30

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.

  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.

  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 Gestion de la capacité de SharePoint Server 2010 : Limitations et frontières logicielles, 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:

  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 Gestion de la capacité de SharePoint Server 2010 : Limitations et frontières logicielles.

    • 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

      Notes

      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.

  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:

  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:

  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 Kit de ressources d’administration SharePoint 2010 (SharePoint Server 2010). These tools can help you test, analyze and troubleshoot your environment.

    For more information about the Load Testing Kit, see Charger le kit de test (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).