This is Part 7 of my series on ‘My Users Don’t Like SharePoint…‘
As your SharePoint matures and grows, it can get considerably larger and complex. Content databases can grow to hundreds of gigs, search indexes grow larger, users rely more on Excel services, additional external business data is pulled in, some custom functionality is added, etc. All of this can impact performance when not implemented correctly.
I look at it like it’s a good sign: your users are using SharePoint! However, as your farm grows, you should monitor the farm and possibly reconfigure and add additional servers to the mix. The first step is to figure out why it’s slow.
It’s so slow, what can I do?!
There’s a lot of reasons SharePoint’s performance can dwindle, here’s a few. This is everything I could dream up, dealt with or heard about. Did I miss something? Leave a comment!
- Is it designed properly? Check out Microsoft’s recommendations for hardware, software and farm architecture to cover the basics. If you’re running your entire farm on a single server, I’d start by adding some more servers. Check out the SharePoint 2010 Technical Diagrams for a great starting point: http://technet.microsoft.com/en-us/library/cc263199(v=office.14).aspx
- A very common slow issue is when SharePoint first wakes up. Since SharePoint is a .Net application running on IIS, the application pools need to spin up, compile all of the assemblies and serve up pages. This can take a few minutes when SharePoint initially starts up. In most cases, once you’re past this slow start up, SharePoint will continue to run smoothly throughout the day. One trick to avoid this slow start up is to keep SharePoint awake. There is a simple PowerShell script which you can schedule in Windows Tasks to run, and it’ll keep hitting your SharePoint sites, thereby keeping them awake. Check it out at http://spwakeuppowershell.codeplex.com.
- Check the Task Manager on your servers. Simple enough, but it tells us a lot. Looking at the stats in Task Manager you can determine which services are taking up loads of RAM or are pinning the processor. If you’re seeing a lot of w3wp.exe processes, take a look at my PowerShell script which marries the w3wp with the process in SharePoint. This might help clarify things a little.
- Sometimes a specific page or two may be loading slowly. Look into all of the web parts on the page. The more you load on a page, the more it has to do. Consider taking some off, or creating another page that can house some of the web parts.
- Community Feedback: Thanks Marc! A large number of closed Web Parts, often on the home pages, will slow down a page. Every closed Web Part causes a small amount of processing overhead, and it can add up. To check this, add ?contents=1 to the page’s URL and remove any Web Parts which aren’t displayed. It can make a huge difference.
- You should configure your content databases in SQL to handle the anticipated usage and traffic. See my older post which also talked about performance, and has more details on databases: Improving SharePoint’s Performance.
- Your content databases can grow up to SQL’s limit, which is in the terabytes It’s not a recommended practice as it does impede the performance of SharePoint. As your site collections grow, consider splitting off site collections to their own content databases. This allows you to manage each database individually, which will help improve performance. Check out this MSDN article on Moving sites between content databases.
- Caching. Storing data closer to where you need it to help improve performance. Instead of sending SharePoint all the way back to the database to get some data, it can read a local cache instead. Check out MSDN article Plan for caching and performance.
- Community Feedback: Thanks paslatek! There is a big performance issue when your server does not have internet access and it tries to validate certificates with clr.micosoft.com. I found this TechNet article which may help.
- Community Feedback: Thanks mansi! Performance issues can be caused by BLOB Storage: since SharePoint saves all the files (documents, images, videos, etc.) in SQL Server in the form of unstructured objects known as Binary Large Objects (BLOBs). Having too many BLOBs can slow down SharePoint’s performance as they take lot of space and require SQL to process more. A solution to work around this issue is to store your BLOBs in a location other than your content database, which SQL refers to as RBS: Remote BLOB Storage. You can read more on this: Storing your SharePoint files outside of the database (RBS).
- Update: Lists and libraries containing several thousand items can slow things down a lot too. Check out TechNet article Designing large lists and maximizing list performance.
Gah, I think that’s it for now. I’m sure there’s more, but these have been the primary reasons I’ve come across, and have seen some great improvements after applying. If I’m missing any, please leave a comment below.
Til next week, Happy SharePointing!
Specifically with BLOB performance… What is the recommended way to isolate that SharePoint performance issues may be related to BLOB transactions?
Great post David. I would like to pinpoint one common issues that you have missed. Performance issue caused by BLOB Storage: Since SharePoint saves all the files in SQL Server in the form of unstructured objects known as Binary Large Objects, so too many BOLBs slow down SharePoint performance as they take lot of space. So you should store BLOBs in a location other than your content database or you can externalize BLOBs using RBS or EBS. Recently my friend has written the article on same: http://tinyurl.com/aterdjb
Thanks mansi, added to the post. Unfortunately your link doesn’t work.
End user behaviour: adding too large pictures, video’s or libraries/lists with far too many items on a site’s homepage. The other day I encountered an example of a huge video on the homepage, which made it impossible to open the homepage and everyone thought the site had been deleted. And thank you for that “closed webpart” suggestion – I had never realized that.
Good list. One thing I run into all the time is a large number of closed Web Parts, often on the home pages. Every closed Web Part causes a small amount of processing overhead, and it can add up. To check this, add ?contents=1 to the page’s URL and remove any Web Parts which aren’t displayed. It can make a huge difference.
The record for the number of closed Web Parts that I’ve seen in the wild is 72. Can anyone beat it?
Awesome, almost added it but forgot the finer details. thanks!
I noticed that some in-house developer used SharePoint lists as SQL tables, that may also cause serious performance issue.
What do you mean by SharePoint lists as SQL tables? High traffic, high amounts of data stored in a list? That’s definitely a problem. Let me know what you think.
You must speak about internet connection on your servers. There is a big issue when your server have not the connection to outside and trying to validate certificates onto clr.micosoft.com. There some great article on the web explaining how to disable the outside call….
Awesome, haven’t come across this one myself, but I’ll add it. Thanks!
I wrote an article a few months ago about the “clr.microsoft.com” .. hope you like it..