This is a guest post from SharePoint Dragons. This post comes from Nikander and Margriet, and you can find the original post here.
There can be a number of reasons for your SharePoint installation suffering from performance issues. Checkout the following tips and tricks to see if they can help get your system healthy again:
- Get to know your application, it’s usage, and it’s response times by studying the IIS logs. One of the ways to do this is to use the free SharePoint Flavored Weblog Reader (SFWR) tool.
- Monitor performance counters that are relevant for SharePoint. This gallery post gives an overview of a set of relevant performance counters that have been established after careful research, and a small PowerShell script for reading them. Also see for a different perspective.
- Even if your environment is already up and running, do capacity planning. This way you can check if you’re crossing any important limits that might threaten performance. Check out here and here. Do remember that content database limits include remote BLOBs (if you use them) and that auditing has a great impact on capacity planning.
- Use the SharePoint Diagnostic Data Provider/Logging database to get more insight into your environment. Check out here and here for more info. Also see this technet article.
- Do performance and stress testing, even if you’re already in trouble. It helps a lot to be able to simulate when a comparable environment gets into trouble. Also see here, here, and here.
- More often than not, performance problems are caused by custom software. Demand that each piece of custom software gets shipped with a configurable diagnostics system that can be used to determine any pain points in there.
- The first authenticated user may experience a very poor response time. Consider warming up SharePoint.
- Follow best practices when using the Content Query Web Part (CQWP).
- Shrink the SharePoint content database transaction log files if they become too big or when it’s size increases abnormally.
- Enable Profile cache.
- Enable object cache.
- Enable output cache.
- Enable IIS compression.
- Configure list throttling.
- Use list indexes.
- Limit the maximum upload file size.
- If you’re working with extremly large files, consider using Remote Blob Storage (RBS).
- Use SQL DMVs to analyze the state of your SQL database server, also taking into consideration the performance of other applications unrelated to SharePoint, but hosted on the same database server.
- If you’re allowed to: enable SQL Profiler to check SQL Server database problems on the fly.
- Study the set up of the database environment, which is crucial for the success of your SharePoint environment. The SharePoint 2010 Administrator’s Companion contains an excellent chapter about this ( available on Amazon)
- Use the SharePoint Dispose Checker Tool (SPDispose) to find memory leaks in custom software.
- Use System Center Operations Manager for monitoring SharePoint or a 3rd party tool like Quest Foglight for ASP. Foglight can capture trends like page load times as well as consolidate performance counters.
- Get the SharePoint Administration Toolkit. It contains a load testing kit that can be employed to determine if an environment is able to handle the current load. It also contains SharePoint Diagnostic Studio 2010, a tool used by Microsoft personnel for troubleshooting. It’s able to capture lots of information about performance counters, ULS log files, and so on. See here for more information.
- Get PAL, a tool for troubleshooting performance troubles. See here and here.
- Use MSOCAF to check code before submitting it to Microsoft for BPOS/Office365.