Designing a Microsoft SharePoint 2010 Infrastructure Vol 1 part 17 ppt

MCT USE ONLY. STUDENT USE PROHIBITED Planning for Performance and Capacity 3-27 Selecting a Farm Topology Key Points It is important to consider farm size and topology carefully when you size a SharePoint 2010 solution for performance and capacity. Farm topologies for SharePoint 2010 fall broadly into three categories: • Small farm. A small SharePoint farm typically has two or three tiers made up from up to five servers. Typically, there is a single database server, and WFE servers may also perform service application roles. A two-tier, three-server farm can serve relatively low usage load (a few requests per minute to a few requests per second (RPS)) and a volume of data in the region of tens of gigabytes. • Medium farm. A topology for a medium SharePoint farm typically has three tiers, with more than six servers. There may be multiple database servers, multiple search servers, and application servers that are dedicated to specific service applications. Multiple WFE servers enable many concurrent user requests. A medium-size farm can serve a usage load of a few tens of RPS and a data volume up to 1 terabyte. MCT USE ONLY. STUDENT USE PROHIBITED 3-28 Designing a Microsoft® SharePoint® 2010 Infrastructure • Large farm. A topology for a large SharePoint farm typically employs in excess of 10–12 servers that are arranged in three tiers. In a large farm, you often logically group servers according to the applications that the servers host. For example, a group of three servers hosting Microsoft InfoPath® forms, or a group of two crawl servers. A large farm can serve usage loads of hundreds of RPS and data storage of tens of terabytes. Additional Reading For more information about topologies for SharePoint Server 2010, see http://go.microsoft.com/fwlink/?LinkID=200856&clcid=0x409. MCT USE ONLY. STUDENT USE PROHIBITED Planning for Performance and Capacity 3-29 Monitoring Performance Key Points To size a solution correctly from a performance perspective, you should perform monitoring of the system under load to ascertain performance characteristics, identify bottlenecks, and establish the capability of the solution to meet business requirements. You can use the Performance Monitor tool in Windows Server® 2008 and Windows Server 2008 R2 to capture performance information from performance objects and counters. Performance objects can include hardware components such as processor or memory. They can also include software components such as Windows® operating system subsystems or the Microsoft .NET Framework. You can also add the performance counters that you need to monitor to the SharePoint Usage and Health Data Collection database, which can then provide a single point for health and performance data. You do this by using the Add- SPDiagnosticsPerformanceCounter Windows PowerShell™ cmdlet. You should capture initial performance statistics under peak load to create a baseline for how the system performs. You should then regularly revisit the MCT USE ONLY. STUDENT USE PROHIBITED 3-30 Designing a Microsoft® SharePoint® 2010 Infrastructure performance information for the live system. This will enable you to capture trend data and identify any areas for performance improvement, if required. The following table describes the system performance counters that you should monitor on any Web server. Counter Object Description % Processor Time Processor This shows processor usage over a period of time. If this is consistently too high, you may find performance is adversely affected. Remember to count "Total" in multiprocessor systems. You can also measure the usage on each processor to ensure balanced performance between cores. - Avg. Disk Queue Length Disk This shows the average number of both read and write requests that were queued for the selected disk during the sample interval. A bigger disk queue length may not be a problem as long as disk reads/writes are not suffering and the system is working in a steady state without increasing the queue length. Avg. Disk Read Queue Length Disk This shows the average number of read requests that are queued. Avg. Disk Write Queue Length Disk This shows the average number of write requests that are queued. Disk Reads/sec Disk This shows the number of reads to disk per second. Disk Writes/sec Disk This shows the number of writes to disk per second. - Available Mbytes Memory This shows the amount of physical memory that is available for allocation. Insufficient memory will lead to excessive use of the page file and an increase in the number of page faults per second. - Cache Faults/sec Memory This shows the rate at which faults occur when a page is sought in the file system cache and is not found. This may be a soft fault, when the page is found in memory, or a hard fault, when the page is on disk. MCT USE ONLY. STUDENT USE PROHIBITED Planning for Performance and Capacity 3-31 Counter Object Description The effective use of the cache for read and write operations can have a significant effect on server performance. You must monitor for increased cache failures, which are indicated by a reduction in the Async Fast Reads/sec or Read Aheads/sec counters. - Pages/sec Memory This shows the rate at which pages are read from or written to disk to resolve hard page faults. If this rises, it indicates system-wide performance problems. - % Used and % Used Peak Paging File The server paging file, sometimes called the swapfile, holds virtual memory addresses on disk. Page faults occur when a process has to stop and wait while required virtual resources are retrieved from disk into memory. These will be more frequent if the physical memory is inadequate. - Total Bytes/sec Network Interface This is the rate at which data is sent and received via the network interface card. You may need to investigate further if this rate is over 40-50 percent of network capacity. To fine-tune your investigation, monitor Bytes received/sec and Bytes Sent/sec counters. - Working Set Process This indicates the current size (in bytes) of the working set for a given process. This memory is reserved for the process, even if it is not in use. - % Processor Time Process This indicates the percentage of processor time that a given process uses. Thread Count (_Total) Process This shows the current number of threads. Requests Total ASP.NET This shows the total number of requests since the service was started. Requests Queued ASP.NET Microsoft SharePoint Foundation 2010 provides the building blocks for HTML pages that are rendered in the user browser over HTTP. This counter shows the number of requests that are waiting to be processed. MCT USE ONLY. STUDENT USE PROHIBITED 3-32 Designing a Microsoft® SharePoint® 2010 Infrastructure Counter Object Description Request Wait Time ASP.NET This shows the number of milliseconds that the most recent request waited in the queue for processing. As the number of wait events increases, users will experience degraded page-rendering performance. Requests Rejected ASP.NET This shows the total number of requests that were not performed because of insufficient server resources to process them. This counter represents the number of requests that return a 503 HTTP status code, indicating that the server is too busy. Requests Executing (_Total) ASP.NET This shows the number of requests that are currently running. Requests/Sec (_Total) ASP.NET This shows the number of requests that are performed each second. This represents the current throughput of the application. Under constant load, this number should remain within a certain range, barring other server work (such as garbage collection or external server tools). The following table describes the system performance counters that you should monitor on a computer running SQL Server. Counter Object Description User Connections SQLServer:General Statistics This shows the amount of user connections on your instance of SQL Server. If you see this number rise by 500 percent from your baseline, you may see a performance reduction. - SQLServer:Databases This object provides counters to monitor bulk copy operations, backup and restore throughput, and transaction log activities. Monitor transactions and the transaction log to determine how much user activity is occurring in the database and how full the transaction log is becoming. The amount of user activity can determine the MCT USE ONLY. STUDENT USE PROHIBITED Planning for Performance and Capacity 3-33 Counter Object Description performance of the database and affect log size, locking, and replication. Monitoring low-level log activity to gauge user activity and resource usage can help you to identify performance bottlenecks. Transactions/sec SQLServer:Databases This shows the amount of transactions on a given database or on the entire SQL Server instance per second. This number is to help you create a baseline and troubleshoot issues. Number of Deadlocks/sec SQLServer:Locks This shows the number of deadlocks on the computer running SQL Server per second. This should be 0. Average Wait Time (ms) SQLServer:Locks This shows the average amount of wait time for each lock request that resulted in a wait. Lock Wait Time (ms) SQLServer:Locks This shows the total wait time for locks in the last second. Lock Waits/sec SQLServer:Locks This shows the number of locks per second that could not be satisfied immediately and had to wait for resources. Average Latch Wait Time (ms) SQLServer:Latches This shows the average latch wait time for latch requests that had to wait. Latch Waits/sec SQLServer:Latches This shows the number of latch requests per second that could not be granted immediately. SQL Compilations/sec SQLServer:SQL Statistics This indicates the number of times the compile code path is entered per second. SQL Re- Compilations/sec SQLServer:SQL Statistics This indicates the number of times statement recompiles are triggered per second. Cache Hit Ratio SQLServer:Plan Cache This indicates the ratio between cache hits and lookups for plans. MCT USE ONLY. STUDENT USE PROHIBITED 3-34 Designing a Microsoft® SharePoint® 2010 Infrastructure Counter Object Description Buffer Cache Hit Ratio SQLServer:Buffer Manager This shows the percentage of pages found in the buffer cache without having to read from disk. The ratio is the total number of cache hits divided by the total number of cache lookups since an instance of SQL Server was started. Note: The SQL Server performance counters are included here for the sake of completeness. Many SharePoint architects will not be SQL Server performance experts. You may want to discuss SQL Server performance issues with an experienced SQL Server database administrator (DBA). Question: What are the four common hardware components to monitor on a server? Additional Reading For more information about how to monitor and maintain SharePoint Server 2010, see http://go.microsoft.com/fwlink/?LinkID=200857&clcid=0x409. MCT USE ONLY. STUDENT USE PROHIBITED Planning for Performance and Capacity 3-35 Performance Management Modeling in SharePoint 2010 Key Points Performance management modeling for SharePoint 2010 includes five key steps: 1. Model. Model the farm environment that you require by establishing the elements or features that you want your solution to provide. Also, determine any required measures such as performance and reliability. The modeling exercise should create: • Expected workload and dataset (volume of data). • Farm performance and reliability targets. 2. Design. Design the farm by using the data from the first step. The design step should create logical and physical architecture designs. 3. Pilot, test, and optimize. Deploy a pilot environment and conduct testing against performance targets. Where necessary, optimize the deployment to meet performance targets or consider revising the solution (for example, change the solution scope or revise the topology). 4. Deploy. Deploy the established solution to the production environment. MCT USE ONLY. STUDENT USE PROHIBITED 3-36 Designing a Microsoft® SharePoint® 2010 Infrastructure 5. Monitor and maintain. Implement monitoring of capacity and performance, identify trends and bottlenecks, and implement maintenance activities when required. While you initially plan your SharePoint farm, you will use the first three steps to identify performance targets, design the farm, and perform testing to determine whether the design meets the required performance targets. Note: Workload describes the demand that the system must sustain. Workload typically uses the label RPS to describe demand on the server farm. It is most common to measure RPS by using all requests in the Internet Information Services (IIS) log except the Authentication handshake requests (401HTTP status). You do not count these because they bias the calculated RPS figure. Question: How can you identify SharePoint performance issues before you create your production environment? Question: What resolution steps can you take to resolve a performance issue at the pilot phase? Additional Reading For more information about capacity planning for SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200858&clcid=0x409. . requests. A medium-size farm can serve a usage load of a few tens of RPS and a data volume up to 1 terabyte. MCT USE ONLY. STUDENT USE PROHIBITED 3-28 Designing a Microsoft SharePoint 2 010 Infrastructure. solution for performance and capacity. Farm topologies for SharePoint 2 010 fall broadly into three categories: • Small farm. A small SharePoint farm typically has two or three tiers made up from. • Large farm. A topology for a large SharePoint farm typically employs in excess of 10 12 servers that are arranged in three tiers. In a large farm, you often logically group servers according