Posted on:
Categories: SharePoint
Description:

I was recently involved in a SharePoint search performance troubleshooting exercise and thought it be helpful to outline my troubleshooting methodology and resolution for people with similar issues.

Application Architecture

The application architecture consists of the following elements:

  • Single web application with single site collection
  • A single database containing all content with a single file in the default file group (not optimized)
  • Two large libraries containing over 100K documents separated using folders
  • Users access the content using "out of the box" enterprise search web parts within minimal customization (custom XSLT for formatting )

Issues:

The following is a list of issues with the environment:

  • Search response times for targeted searches were less than optimal
  • Search response time for keywords and navigating between pages was extremely poor
  • Search queries would time out and sometimes would error out

Troubleshooting Methodology and Resolution

I confirmed the user search experience by shadowing the user and did notice significant performance issues when executing targeted and keyword searches. Users also experienced timeouts and errors when targeting larger document sets during searches. I ruled out the obvious issues such as WFE, APP and SQL Server health by validating performance reports and alert conditions through SCOM. The issue was localized to the web application so I enabled the developer dashboard on the web application by running the following commands:

Stsadm –o setproperty –pn developer-dashboard –pv ondemand

This action allowed me to invoke the dashboard on demand from any page within the web application. I enabled the dashboard on the search site and ran a typical query and here’s a screenshot of the dashboard (issue circled in red)

image1

As you can see from the snippet above page is making two WCF calls to the search service and the corresponding times are unacceptable – what’s more is that I noticed the property "isDocument:TRUE" configured in the search webpart. I proceeded to repeat the process from a generic page with search enabled and results were within acceptable range:

image2

Upon further examination of the page I found two issues.

  • The first WCF call was take a long time because the search webaprt was customized to return complete result set and then filter out the search criteria. I guess there was general lack of understanding how to interface with Search.
  • Second search request was caused by a closed search webpart on the page. Removal of the webpart addressed the subsequent WCF call.

I addressed the first issue by creating search scopes on the site for targeted searches. Here’s a snipped of the search results after implementing search scopes:

image3