This article replicates the technical discussion on capacity planning, we had at the Mindcracker Kerala Chapter meeting on 29th December 2011.
This is our second chapter that we conducted in Trivandrum the capital of Kerala. As we have lot of members from Trivandrum in Mindcracker community especially from Techno Park, we decided to host the event in techno park food court. We had a participation of 12 key members from multiple companies within Techno park, joined the meeting even though have 20 people registered for the event. It is very easy for us to organize the event because we all in one place. Please find below the group photo of our members (Aneesh took the photo).
(Nithya, Simi, Nishila, Jibin, Destin, Biju, Rency, John, Edwin, Binish and Jose)
From left to right
The event started with a welcome drink. Later I explained about Mindcracker, C# Corner and our vision. We started with our Pizza, and capacity planning discussion before Aneesh started the session.
If the preliminary assessment on capacity planning & Management is carried out promptly, then it can really help us in system sizing. Sizing is the term used to describe the selection and configuration of appropriate data architecture, logical and physical topology, and hardware for a solution platform. There is a range of capacity management and usage considerations that affect how we should determine the most appropriate hardware and configuration options for SharePoint.
Capacity Planning is only one part of the capacity management cycle. It is the initial set of activities that brings the design architect to the point where there is an initial architecture that the architect believes will best serve the SharePoint Server 2010 deployment. The capacity management model includes additional steps to help us validate and tune the initial architecture, and provides a feedback loop for re-planning and optimizing the production environment until it can support design goals with optimal choices of hardware, topology, and configuration.
Aneesh sharing his thoughts on SharePoint 2010 capacity Planning
We discussed about various factors that affect the capacity management and planning. We come up with a conclusion that the below factors also should considered. The following factors were decided to be considered as part of the forum discussion
- RPS: Requests per second. The number of requests received by a farm or server in one second.
- Peak hours: The time or times during the day when load on the farm is at its maximum.
- Peak load: The average maximum daily load on the farm, measured in RPS.
- Load spike: Transient load peaks that fall outside usual peak hours.
- Scale up: To scale up means to add resources such as processors or memory to a server.
- Scale out: To scale out means to add more servers to a farm.
Workload
Workload describes the demand that the system will need to sustain, the user base and usage characteristics. The following table provides some key metrics that are helpful in determining your workload. You may use this table to record these metrics as you collect them.
| No |
Workload Characteristics |
Value |
| 1 |
Average daily RPS |
|
| 2 |
Average RPS at peak time |
|
| 3 |
Total number of unique users per day |
|
| 4 |
Average daily concurrent users |
|
| 5 |
Peak concurrent users at peak time |
|
| 6 |
Total number of requests per day |
|
| 7 |
Expected workload distribution |
|
| 8 |
Web Browser - Search Crawl |
|
| 9 |
Web Browser - General Collaboration Interaction |
|
| 10 |
Web Browser - Social Interaction |
|
| 11 |
Web Browser - General Interaction |
|
| 12 |
Web Browser - Office Web Apps |
|
| 13 |
Office Clients |
|
| 14 |
OneNote Client |
|
| 15 |
SharePoint Workspace |
|
| 16 |
Outlook RSS Sync |
|
| 17 |
Outlook Social Connector |
|
| 18 |
Other interactions(Custom Applications/Web services) |
|
- Concurrent users - It is most common to measure the concurrency of operations executed on the server farm as the number of distinct users generating requests in a given time frame.
- Requests per second (RPS) - RPS is a commonly used indicator used to describe the demand on the server farm expressed in the number of requests processed by the farm per second, but with no differentiation between the type or size of requests.
- Total daily requests - Total daily requests is a good indicator of the overall load the system will need to handle.
- Total daily users - Total users is another key indicator of the overall load the system might need to handle. This measurement is the actual number of unique users in a 24 hour period, and not the total number of employees in the organization.
Estimating your production workload
In estimating the required throughput your farm needs to be able to sustain, begin with estimating the mix of transactions that will be used in your farm. Focus on analyzing the most frequently used transactions the system will serve, understanding how frequently they will be used and by how many users. That will help you validate later whether the farm can sustain such load in pre-production testing.
The relationship of the workload and load on the system
Identify system operations such as Search incremental crawls, daily backups, profile sync timer jobs, web analytics processing, logging timer jobs and others. Estimate the total number of users per day that are expected to utilize each capability, derive the estimated concurrent users and high level Requests per second, there are some assumptions you will be making such as present concurrency and the factor of RPS per concurrent users that is different across capabilities, you may need to use the workload table earlier in this section for your estimates. It is important to focus on peak hours, rather than average throughput. By Planning for peak activity, you will be able to derive a proper solution for share point 2010 server; this marked the end of session by Aneesh. Next the turn of Binish to quote his ideas on Capacity planning of large SharePoint farm.
Binish delivering speech on SharePoint 2010 capacity Planning
To maintain system performance, we must monitor keenly monitor our server to identify potential bottlenecks. Before we can monitor effectively, we must understand the key indicators that will tell us if a specific part of our farm requires attention, and know how to interpret these indicators. If we find that our farm is operating outside the targets we have defined, we can adjust our farm by adding or removing hardware resources, modifying our topology, or changing how data is stored.