Updated Best Practices for SharePoint capacity management documentation on TechNet

  • Article

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)

  1. 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).

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

  3. 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:

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

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

  6. 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:

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

  8. 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:

  9. 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:

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

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