As Microsoft SharePoint 2010 brings many more enhanced features and power to organizations and end-users, it also brings complexity and many new parameters to take care of and tweak for an optimal performance and a healthy environment. SharePoint doesn't operate in a vacuum; it relies on the Windows Server System and its various components for platform services. In addition, SharePoint makes use of SQL Server as its datastore. When you think of SharePoint, think of the full picture and its constituents. Another angle you should look from is the SharePoint features you are using in your environment. You should only focus on the components and services you activate, and disable/deactivate services and features you don't use, thus relieving the server from the overhead entailed from managing these services and features.

This post will provide you with a preliminary set of activities, tools, and techniques for you to ensure that your SharePoint farm is performing well and according to the measures you set; the definitions for what good performance is. To start with, Windows Server 2008 or Windows Server 2008 R2 is the OS for your SharePoint farm. The health of Windows has an impact on your SharePoint farm, and in many cases a performance bottleneck can be observed in the Windows system or its underlying hardware. So how do we diagnose our Windows Server for any problems or bottlenecks at the lowest level? We monitor a set of essential performance counters. These performance counters can give you a general idea on the health of your servers. I recommend this fantastic article "Taking Your Server's Pulse" http://technet.microsoft.com/en-us/magazine/2008.08.pulse.aspx?pr=blog for an introduction to the various types of performance counters you can monitor with PerfMon (Hard Disk, Memory, Processor, and Network). In addition, pay close attention and observe the set of performance counters listed in the "Monitoring and maintaining SharePoint Server 2010" http://technet.microsoft.com/en-us/library/ff758658.aspx.

Move up to the data layer and SQL Server has it all. As most of your content and configuration information is stored in SQL Server databases, you should optimize and fine-tune your SQL Servers to ensure that SharePoint has fast access to it various databases (Content, Farm Config, Service Applications, etc…). Moreover, configure your SQL Server for SharePoint as recommended by the SharePoint team. For example, set SQL Server options as listed below.

  • Do not enable auto-create statistics on a SQL Server that is supporting SharePoint Server
  • Set max degree of parallelism (MAXDOP) to 1
  • To improve ease of maintenance, configure SQL Server connection aliases for each database server in your farm

Refer to the article “Storage and SQL Server Capacity Planning and Configuration (SharePoint Server 2010” http://technet.microsoft.com/en-us/library/cc298801.aspx for more information on configuring SQL Server for SharePoint.

Last but not least, we reach the heart of our talk – SharePoint Server 2010. Whenever I login into central administration I check the health analyzer for a quick overview on the health of the farm. The built-in health analyzer has predefined rules to check against and can provide automatic fixes for some of the rules. These rules should give you a general idea on your SharePoint’s health. The article “SharePoint Health Analyzer rules Reference” http://technet.microsoft.com/en-us/library/ff686816.aspx is the place to look for the definitions of these rules.

Second, I use SPDiag from the SharePoint Administration Toolkit to review ULS, IIS, and Event logs to spot any major issues logged in the farm. “SharePoint Diagnostic Studio 2010 (SPDiag 3.0) provides SharePoint administrators with a unified interface that can be used to gather relevant information from a farm, display the results in a meaningful way, identify performance issues, and share or export the collected data and reports for analysis by Microsoft support personnel”. See http://technet.microsoft.com/en-us/library/cc508851.aspx for more details.

Third, I use SPDisposeCheck, the SharePoint Dispose Checker Tool to check for any memory leaks in any custom code deployed in the farm. “SPDisposeCheck is a tool that helps developers and administrators check custom SharePoint solutions that use the SharePoint Object Model helping measure against known Microsoft dispose best practices. This tool may not show all memory leaks in your code and may produce false positives which need further review by subject matter experts.” See http://archive.msdn.microsoft.com/SPDisposeCheck for more details and to download the tool.

Finally, I always check with farm users and listen to any concerns and/or any problems they face while working with SharePoint. Users are those who will define what an acceptable behavior is in most of the cases!

Good luck managing and monitoring your SharePoint 2010 Farm!