Chris Hines

I’ve been working on a FAST Search for SharePoint project which has required some close attention to SAN IO and how it may be affecting FAST search throughput. I found this article really useful for setting up benchmark tests:

http://sqlserverpedia.com/wiki/SAN_Performance_Tuning_with_SQLIO

SQLIO is a Microsoft tool but this article and video by Quest shows how to use it effectively.

Also, Eric Belisle talks specifically about FAST Search pipeline performance here:

http://fs4sp.blogspot.com/2011/06/fs4sp-pipeline-performance-and.html

Is your content SSA not speaking to FAST? Does it look like your crawl started but nothing is making it to your FAST server(s)?

If you see an  error message like ‘Unable to resolve Content distributor’ in your FAST search content SSA logs it’s likely something went wrong with the SSL certificate used between the content SSA and FAST. If you used a self-signed certificate during the FAST installation the certificate will by default expire after one year. It’s possible to extend this time period for a self-signed certificate, see this post by Mikael Svenson:

http://techmikael.blogspot.com/2011/01/will-your-fast-search-server-for.html

I first encountered the above error due to assigning new IP addresses to various servers in my farm. I found this article useful when debugging the issue:

http://blogs.pointbridge.com/Blogs/tseng_william/Pages/Post.aspx?_ID=13

In addition, I found that a reboot of my content SSA server was required after the first SecureFASTSearchConnector.ps call failed. Still not sure why this failed.

After generating a new FASTSearchCert.pfx I followed the original Technet instructions for how to secure the SSA:

http://technet.microsoft.com/en-us/library/ff381261.aspx#BKMK_Configure_ssl_enabled_communication

I’m finding that my FAST servers are using a lot of CPU and Memory in the later stages of a crawl. It looks like this is probably due to my definition and re-definition of FAST managed metadata. For example, I had some metadata properties which were set to ‘dynamic’ when really ‘static’ would have been more appropriate. It seems that even changing these properties on my metadata causes a lot of processing by fixmlindex.exe.

I’m going to pursue the suggestions in this post:

http://social.technet.microsoft.com/Forums/en-US/fastsharepoint/thread/5ef1b42b-e90d-40c8-a228-8d4ffcd0acc7/

It sounds like I should really get my metadata 100% correct, first time. That’s tricky because it’s not until one starts using, searching and refining by metadata that we realize whether it’s the right size and shape.

I build a lot of custom result pages for SharePoint (and FS4SP). A lot of these pages follow a similar pattern and I decided they were becoming a maintenance liability. I wanted a way to parametrize the page and generate something which looked different for each search scope. I am somewhat of a reluctant XSLT developer but found a good solution using the CoreResults WebPart.

I added:

<ParameterBinding Name=”url_PATH_INFO” Location=”ServerVariable(PATH_INFO)” DefaultValue=”"/>
<ParameterBinding Name=”url_HTTP_HOST” Location=”ServerVariable(HTTP_HOST)” DefaultValue=”"/>
<ParameterBinding Name=”url_QUERY_STRING” Location=”ServerVariable(QUERY_STRING)” DefaultValue=”"/>

to the Parameters property of CoreResults. I then added

  <xsl:param name=”url_PATH_INFO” />
  <xsl:param name=”url_HTTP_HOST” />
  <xsl:param name=”url_QUERY_STRING” />

to the head of my CoreResults XSLT.

I was then able to parse the url_QUERY_STRING for the ‘s’ scope parameter and customize my page accordingly. I also used url_PATH_INFO and url_HTTP_HOST for creating some other links on the page.

Thanks to this article by James Curtis for showing how to extract the server variables and pass them to XSLT:

http://www.jwc3.net/2008/05/how-to-get-url-in-xsl.html

It’s fairly disappointing that SharePoint 2010 does not offer full FAST FQL queries from the SharePoint 2010 UI. I’m in a position where I would like to provide our high-end search users with the option of writing a full-blown FQL query. Our users will be most interested in writing detailed proximity searches specifying the distance between words.

e.g.

NEAR(chris,skydiving,n=20)

It seems to me that there is a rich and useful query language which we cannot easily utilize!

The good news is that it’s possible to enable FQL queries. There’s a property called EnableFQL on the KeywordQuery object which we can set to TRUE. However, the bad news is that this is not accessible from CoreResultsWebPart due the inheritance of this class and the fact that it’s marked internal. This means that we cannot inherit from CoreResultsWebPart and expect to EnableFQL. This is a real shame because I want all of the good functionality contained in CoreResultsWebPart.

So we have two options:

1. We write our own results WebPart from scratch. This is perfectly possible the only questions, like most things in life,  are of time and money :)

2.  I found an interesting article which describes how to delve into the KeywordQuery object via reflection when extending CoreResultsWebPart.

http://neganov.blogspot.com/2011/01/extending-coreresultswebpart-to-handle.html

Of course this will not be a supported route but could save a lot of time and money!

Mikael Svenson describes the problem here:

http://techmikael.blogspot.com/2010/11/why-enterprise-search-web-parts-are.html

Decisions decisions! ….

If you are missing the following links from your Site Collection Administration

FAST Search keywords
FAST Search site promotion and demotion
FAST Search user context

You are missing a feature activation for the site collection. On the search site collection activate it using Powershell.

Enable-SPFeature -id “5EAC763D-FBF5-4d6f-A76B-EDED7DD7B0A5″ -Url [SiteUrl]

Credit to:

http://devdotnotes.wordpress.com/2012/01/27/missing-fast-search-keywords-site-promotion-and-demotion-user-context-from-site-collection-administration/

for this useful nugget.