Freigeben über

How to calculate Throughput and Peak Throughput for SharePoint

  • Artikel

While doing capacity planning for SharePoint, Throughput and Peak Throughput are two very important parameters that later help you decide on the number of servers/hardware required for your SharePoint implementation.

Lets start of by looking for Throughput first.

Throughput is the number of operations/requests that a server can handle per second. Throughput is measured in requests per second (RPS). RPS measurements can be converted to the total number of users by using a model based on typical user behavior. The user model for SharePoint 2010 has the following two variables :

  • Concurrency—the percentage of users that are actively using the system.
  • Request rate—the average number of requests per hour that an active user generates.

It is possible to calculate a rough throughput guideline for typical loads in the following way:

(Number of users X Percentage of users who are active) ÷ Request rate

Example : (700 users X 10% concurrent users) / 30 request rate per hour = 70/30 = 2 RPS ( approx)

 

To estimate peak throughput, it is necessary to calculate the maximum number of pages per second that are likely to be requested in any given scenario. The following list provides key sizing metrics, along with typical values as a guideline:

A. Number of users: The total number of users that have access to SharePoint which is 700 in this case.

B. Percent of active users per day: The percentage of the users who might access SharePoint during the day. In this case its assumed to be 10% which is = 70 active users

C. Operations per user per day: Accesses to the home page, searches, browsing, document retrievals, media  viewing, and so on. Like in most organizations, the estimated operations for this per user per day = 30.

D. Hours per day: Hours in the business day = 8 hours.

E. Peak factor: A ratio of how much the peak usage exceeds the average usage. The system is generally sized for peak usage so that performance does not degrade during busy periods. A typical ratio is 5:1.

Given that there are 3600 seconds per hour, the following formula calculates the peak number of requests per second:

(A x B x C x E) ÷ (3600 x D)

(Number of users x Percent of active users per day x Number of operations per active user per day x Peak factor) ÷ (3600 x hours per day)

Applying this formula gives:

(700 x 10 x 30 x 5) ÷ (3600 x 8) = 37 RPS (which is Peak Throughput)

Typical

Total Number of users (A)

700

  % of Active users  per day (B)

10

Operations per user per day (C)

30

Peak Factor (E)

7

Hours per day (D)

8

Estimated Operations per second (rounded)

37

Two quick formulae to calcuate size of crawl database and property database in SharePoint 2010

  • Crawl DB = 0.023 X ( sum of all content DB's)
  • Property DB = 0.015 X (sum of all Content DB's)

Good Post on calculation of no. of WFE required : https://www.cjvandyk.com/blog/Lists/Posts/Post.aspx?ID=100

Performance Analysis Template : Attached with this email ( Thanks to Sanjay for sharing this). More info. about the template, please look into https://blogs.msdn.com/b/sanjaynarang/archive/2012/06/05/performance-testing-analysis-template-for-sharepoint-server-2010.aspx

Hope the blog post was helpful!..

 

 

Performance Testing Analysis template for SharePoint 2010.xlsx

Comments

  • Anonymous
    September 20, 2012
    Good Article.

  • Anonymous
    January 13, 2013
    hi, when calculating the request rate per hour , you placed it as 30 in the second calculation , when calculating the operations per day you placed it 30 as well !! I think request rate per hour should equel to = operations per day / number of working hours , in your case it should be 30/8 hours = 3.75 or lets round it to 4 requests per hour per user cheers :)

  • Anonymous
    July 14, 2014
    In Italics at the top, the percentage of users is correctly calculated but below it is not.  It is correctly described as 70 users in "B" but in the calculation it is multiplied as an absolute value rather than a percentage (making it out by a factor of 100).  Further, these calculations describe operations per hour but 30 would equate to around 2-3 pages at around 10-15 requests per page (JavaScript, CSS, etc.) which seems rather low.