My Users Don’t Like SharePoint because it is too slow!

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.

SharePoint's w3wp list

  • 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.
  • If all pages are doggy, and you have a custom design, it may be a good idea to look into the assets of the design: images, CSS and JavaScript files. If these aren’t sized correctly you might experience slow performance. There are applications available that can assess a page and tell you what’s slow and how large the assets are. I like to use YSlow, and add on for Chrome, gives some pretty neat stats:

SharePoint page stats using YSlow

    • One note about these types of page stats in SharePoint. There are going to be some elements you’re stuck with, namely this first result page. SharePoint has a long list of JavaScript files which are necessary and can’t be removed. These will always skew these stats. Fortunately, the files are minified (art of shrinking a file by removing wasted space) to minimize download time.
  • 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!

Advertisements

13 thoughts on “My Users Don’t Like SharePoint because it is too slow!

  1. Pingback: My Users Don’t Like SharePoint…New Series! | David Lozzi's Blog

  2. paslatek

    Hello
    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….

    Reply
  3. Eric Fang

    Nice post!

    I noticed that some in-house developer used SharePoint lists as SQL tables, that may also cause serious performance issue.

    Reply
    1. David Lozzi Post author

      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.

      Reply
  4. Marc

    David:

    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?

    M.

    Reply
  5. Ellen van Aken

    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.

    Reply
  6. mansi

    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

    Reply
  7. Tim

    Specifically with BLOB performance… What is the recommended way to isolate that SharePoint performance issues may be related to BLOB transactions?

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s