Microsoft has a formula for calculating farm size (as a starting point) but it lacks some aspects of reality. To help SharePoint Architects with calculating REAL numbers I’ve modified the formula slightly based on what I’ve seen my clients experience.
What’s the difference with the formula? Reality. Most organization don’t have a real governance program, capacity plan and provision environments over capacity. Why? Because management doesn’t have the balls to stop the business from over customizing and provisioning SharePoint into the ground. See it all the time and suspect your reading this because you have experienced this as well.
The formula modifications include:
- Custom code packages are deployed and you don’t have a Quality Assurance department that performance and resilience test (CC) – Yes = 1.25 and No = 0
- All stakeholders participate in the Governance program (NG) – Yes = 0 and No = 1.5
- Your organization is full of incompetence (ID10T) – Yes = 1.5 and No = 0
Generally, you will often need to calculate workload to estimate the number of servers that you require for adequate throughput. You can calculate workload by using a worksheet to identify the number of concurrent users and the average number of requests each day. The following table outlines an example worksheet.
|Total number of users (Tu)|
|Concurrency rate (Cr)|
|Peak usage ratio (Pu)|
|Hours in the business day (H)|
|Custom Code (CC)|
|No Governance (NG)|
You can then apply the following formula to estimate the number of Requests Per Second (RPS):
Requests Per Second = (Tu × Cr × Pu × Rd × CC × NG × ID10T) ÷ (H × 3600)
The key message? Do your planning (and not in a bubble) and be prepared to scale for capacity over 5-7 years beyond whats been communicated (Read my blogs on capacity planning and testing), revisit every 4-6 months and factor in risk such as company Dogma, over provisioning and technical risks.
I hope you enjoy using this formula, please suggest improvement such as your own special metrics :)