This article is from our latest EBook named Essentials of capacity Planning SharePoint 2010
Capacity management spreads the concept of capacity planning to prompt a recurring approach in which the capacity of a SharePoint Server 2010 deployment is continually observed and optimized to accommodate changing conditions and requirements.
Capacity management is an ongoing process, because no application remains static in terms of content and usage. You need to plan for growth and change, so that your environment can continue to deliver an effective user experience. SharePoint Server 2010 supports increased flexibility and can be configured to withstand usage scenarios in a wide variety of different scale points.
The following figure 1 show the steps we need to follow while dealing with SharePoint 2010 capacity planning
Modeling is the processes by which we decide the key solutions that we want our environment to support, and establish all important metrics and parameters. We have to take care of the following things when we use modeling.
Concurrent users (number of distinct users at any time)
Requests per Seconds (RPS) - This workload can be hard to estimate but may be gauged through performance testing from use cases or monitoring during a pilot/test phase
Total daily requests
Total daily users
Once we are done with Step 1, we can design our farm. Outputs are detailed data architecture and physical and logical topologies. This is one crucial step we need to go through.
o Determine your starting point architecture.
o Select your hardware.
Pilot, Test, and Optimize
Once we have designed a new deployment Architecture, we need to deploy a pilot environment for testing against our workload and expected usage characteristics.. The output from this phase is analysis of test results against targets, and an optimized architecture able to sustain established performance and capacity targets.
We should include performance testing in your SharePoint strategy. There are some good tools out there for testing; from our experience we recommend use of Microsoft Visual Studio 2010 load tests or the open source project SharePoint Performance Tests.
For optimization, we can look at performance logs or the Development Dashboard feature, which runs on the SharePoint server page and breaks down requests into segments so that you can analyze time taken for execution per request/component. Developer dashboard is a very good feature that helps us to analyze the requests.
We can enable caching which can have a dramatic impact on CPU usage on the SharePoint server and lower requests to the database tier. Caching strategies should be a part of any SharePoint strategy and rollout.
Pilot: Deploy a pilot environment.
Test: Test against latency and throughput targets.
Optimize: Gather test results and make any required changes to the farm topology
In this phase we have to go with implementing the farm. Output for a new design is a completed deployment to live production, including all content and user migrations.
Monitor and maintain
On this phase we have to set up monitoring, and how to predict and identify blocks and perform regular maintenance and bottleneck moderation activities.