This article provides some information on how to optimize a SharePoint deployment. The architectural planning that you conduct before you deploy SharePoint 2013 should ensure that your initial deployment is well placed to satisfy the needs of the organization. However, a SharePoint Deployment is a dynamic entity; databases grow, site collections are added and user distributions and behaviors change. Reviewing and optimizing the configuration of your deployment on a regular basis will help to maintain performance at an optimal level.
Quantifying Performance
Typically, the performance of a web platform such as SharePoint is quantified using four keys.
Measures: latency, throughput, data scale and availability.
Latency
Latency is the time that elapses between the user performing an action and the client receiving, and possibly displaying, the data. For example, it is the time that elapses between the user clicking a link and the client displaying the destination page. Typically, latency includes the time from the client sending a request to the server, the server processing the client request, the server sending a response to the client and the client processing or rendering the response. SharePoint 2013 latency can suffer in many different areas, including:
- Network latency, also referred to as round trip time (RTT).
- Available network bandwidth, which affects how long it takes to send back the entire of the response.
- Uncompressed data transmission.
- Custom code elements, such as Web Parts or features that are not well optimized.
You can only determine the server processing and client rendering elements of latency through performance testing. However, you may have access to case studies that can provide a benchmark to assist in determining general requirements.
Throughput
Throughput is the number of requests that a server farm is able to process in a fixed period. To create a SharePoint farm solution that satisfies user requirements, you should:
- Estimate the expected load.
- Conduct performance testing against the suggested configuration.
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.
You can apply the following formula to estimate the number of requests per second:
Requests per second = (Tu × Cr × Pu × Rd) ÷ (H × 3600)
In this formula:
- Tu is the total number of users.
- Cr is the average concurrent number of users.
- Pu is the peak usage ratio.
- Rd is the average number of requests each day by each user.
- H is the number of working hours in the day.
- 3,600 is the factor to convert hours into seconds.
Data scale
Data scale is the body of data or content that the server farm holds. Generally, greater volumes of data reduce throughput, but data distribution across different servers and storage media can also have an effect.You can calculate data scale based on certain information about content storage, or you can estimate data scale based on the storage requirements in your current environment. Certain data operations can also affect throughput or latency because SQL Server invokes database locks to prevent conflicting operations.
Reliability
Typically, many administrators consider reliability as uptime. However, in the context of performance management, reliability is a measure of the time for which the farm can meet all performance targets. This should include coverage of peak load times. Peak load times may be when the highest number of users are logged on, or when search crawls are running, or when backup tasks are running. Many organizations will have a reliability target that is expressed as a number of nines. The following list shows some example reliability figures with the corresponding calculated time value.
Reliability value Permissible downtime each month:
- 99 percent (two nines) 7 hours
- 99.9 percent (three nines) 43 minutes
- 99.99 percent (four nines) 4 minutes