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