Troubleshooting SharePoint Sluggishness Part 2 (Site Side Issues)

In this follow-up to his first post on Troubleshooting SharePoint Server-Side & SQL Slowdowns, Support Engineer Eric Lough describes the steps for diagnosing sluggish performance on the Site Side of things.

If you’re reading this then, most likely, you have already ruled out server side problems as the source of your SharePoint Sluggishness. The next step starts with possible site side problems that can cause the dreaded sluggishness.

First of all, you should attempt to identify any changes that may have been made if the site was not acting in this manner previously. This would obviously do wonders for pinpointing the problem, but unfortunately, most of the time this information is “unavailable”.

This leaves the pinpointing up to you. That means first identifying the symptoms to help narrow down the exact cause of slow SharePoint site performance. Then you can try to find solutions.

Does your site timeout? Do you get errors when trying to edit a page? Does the site just move really slow and render poorly? These are all signs of sluggishness. The next thing to determine is if the problem is affecting the entire Site Collection or a particular Site or Subsite.

If the entire Site Collection is affected, (typically not the case if server side troubleshooting turned up nothing), then the following should be considered:

  • Crawl Schedule – How often do your crawls run? Does the crawl schedule coincide with times of sluggishness?
  • Database Size – Is your database well over the Microsoft Recommendations? If you have one large database, this can contribute to a bottleneck due to the massive reads/writes/locks that will take place. Pre-planning is essential here as having multiple databases for a Web Application is easy to do in advance, and extremely painstaking to correct in the future. (Typically once your database is at 100-200GB, it’s time to start another).
  • Custom Code – Do you have a custom template using custom code? Un-optimized code can cause latency as well. Usually this would be limited to a particular Site or Subsite, but if placed into a template that is used widely across the Site Collection, this can cause major sluggishness on a wide scale. Investigate sandbox solutions to test this on a smaller scale before implementation in order to prevent this.

*Also, you should consider implementing resource throttling to prevent over-utilization by Services and Sandboxed Solutions.

So you may ask, well what if it’s limited to a particular Site or Subsite? Well then we get a little more development oriented in our troubleshooting. This is also the most common problem you’ll encounter once server side problems have been ruled out.

The first thing I do is attempt to open the problematic site in Chrome. Why? Well, simply put, the Chrome browser handles scripting faster than IE or Firefox. Therefore, if a site works in Chrome but times out in IE or Firefox we can be certain that something on the page is causing the latency.

The first problem is we need to be able to access the Site. If you are encountering such sever sluggishness that you are unable to render the site in any browser, and are receiving timeout errors, you will need to increase the timeout settings on the server. (You should also be able to open the Site or Subsite in SharePoint Designer, but may need to still increase the timeout settings in order to do so). Here’s a helpful article on increasing timeout settings in IIS.

This is not a fix however, just simply a temporary setting needed in order to access the site and fix the problem.

Once the site can be accessed, the first thing to check for is any large Lists or Libraries that are displaying many items at once. Typically an Administrator of a List or Library may have increased the default for how many items are displayed initially, which can bring down the entire Site! Another possibility is that many new items were added to a List or Library whose setting for default items displayed is already too high. This setting is actually a setting on the default view of the List or Library, not the List or Library itself. Simply changing the default view to a more restrictive one can solve the problem, and is an effective method for testing each List or Library in order to find a problematic one; as is simply closing the web part, (which can easily be re-opened).

Reducing the Number of items to display is a simple procedure. Just navigate to the List or Library in question and click the Library tab. Ensure that the Current View: is your default view. Now click Modify View. Now you will expand “Item Limit” and can reduce the number of items displayed as seen below.

SharePoint screenshot: Expand Item Limit

Alternative solutions are to use folders or archive old items.

So what if Large List and Libraries are not the problem? Well, then we need to do a little bit of debugging, and see if any content we have on our page is having trouble rendering.

There are several good tools available for this purpose. Firefox has a really good one called Firebug that is an add-on. However, since we’ve already been using Chrome to this point, Chrome actually has a built in tool that we can use.

Go ahead and open the problematic Site in Chrome. Next click the wrench icon and move your mouse down to Tools. Now click developer tools. From the Developer Tools pane (shown below), we will select the Network tab. Now press F5 to reload the page. It will look like the screen shot below

Chrome Developer Tools screenshot: troubleshooting SharePoint site

Do you have any pieces of your site that are taking a long time to render? If so, where does this content pull from? Do you have any content that couldn’t be found or rendered at all, (will be highlighted in red)?

These items may need to be addressed as they can add to the sluggishness of the site, and can even be the root cause of it. While you may not be a developer, this information can at least pinpoint the problem, even if you do not have the coding knowledge required to fix it.

I hope this information helps. By no means is this the complete guide and guarantee to solve every “Site is Slow” problem, but it should help solve the majority of them as these are the common issues I encounter time and time again when dealing with SharePoint Sluggishness.

As always, thanks for reading and please leave a comment if you have any questions!








2012-08-02T02:58:33+00:00 August 2nd, 2012|

6 Comments

  1. mansi November 22, 2012 at 6:22 am - Reply

    SharePoint Slow performance is a common problem and sometime back I had also suffered with this. You have pinpointed some really good points in your article. Thanks Eric for this useful information.

  2. Rajeev Saklani December 6, 2012 at 7:22 pm - Reply

    Hi Eric,
    Really great article for sharepoint trouble-shooting.

    Thanks a lot

  3. Faizel Mootheril July 26, 2013 at 11:43 am - Reply

    Thanks Eric. It did not resolve my problem but you showed me a free tool that can show the stats on the elements of a SharePoint (2010 in my case) page. In addition, I was just discussing about the fastness of Chrome in loading SharePoint and did not know the reason till you mentioned about the ability to handle SCRIPTING better than IE or Firefox. Thanks!

  4. Rebecca August 16, 2013 at 8:10 am - Reply

    Hi Eric,

    I have a problem in my sharepoint 2007 site. When i rename a folder either by using browser or Windows Explorer it gets renamed instantly but page does not refresh and times out while getting back to Root Folder. In explorer it just hangs. The new name is reflected aftr i f5 the explorer. this is the case only for folder rename. files rename just works fine.

    Please suggest.
    Thanx

  5. Eric Lough August 19, 2013 at 11:53 am - Reply

    Hello Rebecca,

    Typically I would try to narrow down what the problems could be.

    SQL could be a problem, however if this were the culprit one would suspect that all Edits would be subject to the same sluggishness.

    The editform.aspx for the site could have been incorrectly edited, but this could be ruled out if you have not edited it.

    When I am unsure about something, I start with the easiest to rule out first. I would suggest first adding the site to your Intranet Sites Zone in your IE browser. I know this occurs with Explorer View as well and that Intranet Sites Zone is a browser setting, but it may help with both surprisingly and only takes about 1 minute to implement.

    However, this does not sound like normal latency since it is caused by a specific action. I would attempt to edit a file and immediately check Event Viewer on the Web Front End and the SQL Server and see if any errors or warning can give you an indication from where to start, (if Intranet Sites Zone does not help first).

    **Typically one would have folders if using large lists or libraries which can have a huge SQL overhead. I would also check the setting of the list or library and look to see if you have an error on the settings page mentioning that your list or library has exceeded the threshold.

  6. Achraf Loudiy August 6, 2014 at 10:43 am - Reply

    Great article 🙂

Leave A Comment