Poor performance is one of the most frustrating problems SharePoint administrators have to deal with. All too often,...
SharePoint deployments experience steady performance degradation. This can happen as a result of heavier use or an increasing content collection. But it's up to the administrator to track down the underlying cause of the performance problem and correct it.
SharePoint performance problems typically can be attributed to one or more of three main causes. Once you know these three causes, troubleshooting becomes easier and you can improve SharePoint performance.
Cause #1: Poor design
SharePoint is one of Microsoft's most complex applications, and one consequence of that complexity is the straightforward process that makes deployment easier. But SharePoint is often deployed in a less than optimal manner due to a lack of knowledge or budget constraints. A poorly designed SharePoint farm might perform adequately at first, but performance tends to diminish as the workload or content collection increases.
There is no universal fix for a flawed design. Every organization's SharePoint deployment is different, so it's up to the individual administrator to find and correct the problem. The good news is that unless you have a standalone SharePoint deployment, your performance problems will likely be easy to correct. For example, a common design flaw involves using the same physical network segment for user traffic and database traffic. This can be corrected by adding an additional network interface card and redirecting traffic streams. Other performance problems could be solved by moving the resource-intensive SharePoint components to another server.
Cause #2: Storage bottlenecks
The vast majority of SharePoint performance problems can be attributed to storage bottlenecks. The storage connectivity doesn't provide adequate bandwidth, or the storage subsystem can't deliver a sufficient number of IOPS.
One obvious way to improve storage is to use solid-state drives, but the sheer volume of data that SharePoint deployments commonly store tends to make SSDs cost-prohibitive. A better option is to place your transaction logs on SSD storage; flash appliances work especially well for this. Transaction logs are usually the bottleneck for SharePoint storage, so it makes sense to place them on the fastest-available storage medium, even if that medium is something other than SSD storage.
Another thing to consider is the way your SharePoint data is being stored as Binary Large Objects (BLOBs). By default, these BLOBs are stored in a SQL Server database, but SQL Server doesn't efficiently handle unstructured BLOB data.
Some organizations have found they can improve SharePoint performance by moving BLOB data out of SQL Server and onto a file server via Microsoft's Remote BLOB Storage application programming interface. The nice thing about this approach is that it greatly reduces the SQL Server footprint by offloading the actual data to a file server. When properly implemented, this approach can greatly improve SharePoint performance and scalability.
Cause #3: Inadequate memory
SharePoint tends to be a memory-hungry application. As such, begin your performance troubleshoot by making sure that your SharePoint servers aren't running low on memory.
If you're running SharePoint in a virtual machine, make sure the virtual machine is not configured to use dynamic memory, because it isn't supported.
The distributed nature of SharePoint deployments can make performance troubleshooting difficult, but there are plenty of tools that can help you track down performance problems. The Windows Performance Monitor and the System Resource Monitor are both helpful and are both included with Windows. Other helpful tools you could consider are the SharePoint Best Practices Analyzer and System Center Operations Manager.
About the author:
Brien Posey is an eight-time Microsoft MVP for his work with Windows Server, IIS, Exchange Server and file system storage technologies. Brien has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once responsible for IT operations at Fort Knox. He has also served as a network administrator for some of the nation's largest insurance companies.