none
Server Search: Some users experience very long query latencies

    質問

  • First of all our environment:

    • 2 WFEs
    • 2 App Server: 1 Index- and Query, 1 Query-Only
    • 1 Mirrored Database Server

    Whole environment is at Dec CU 2011. Search indexes SharePoint and FileShare Content, 3.3 Mio items are in the index and FT Index on disk has around 25GB of data.

    Now the problem:

    Query latency is at a wide range for different users. The more permissions a user has, the shorter query latency is. For the same search word, we get these results:

    • Admin Users with ~44,000 results: Max 1 Second
    • Normal User with ~2,500 results: Up to 30 Seconds, sometimes a few seconds more or less
    • Guest User with <2,000 results: Query runs into a TimeoutException, because it is taking longer than 90 seconds

    I couldn't find any configuration problem yet. Fact is, that the Query Server the query is forwarded to utilizes one complete CPU for the whole time. Very low SQL Server or disk activity on every system, only CPU on the Query Server.

    I already examined the Administration Reports, and there we see that the latency is split up between Full Text Query and Property Store Query.

    Can anyone give me a hint on what to look for? Thanks in advance!


    // Tried and true method for weather forecasting - random numbers. String weather = (new Random()).Next(2)==0?"rainy":"sunny";


    • 編集済み Uwe82 2012年2月21日 8:16 Title Changed
    2012年2月21日 8:01

回答

  • We found the reason for this long latencies. It was the refinement panel as I find out through digging into the Searches' verbose logs. The Refinement Panel webpart's setting that tells him how many result items should be included was set to 500 (maximum possible value). Because of this, the Query Server tried to fetch 220,000 rows from the index including metadata after the first wave of 2,400 items. This took a long time.

    After going down to around 150 items, latencies are ok again. Splitting the index (complete index has 3.6 Mio items) would increase a good value to 250, but cannot be done atm. Hardware itself is not a real problem, because IO is ok throughout all systems. Problem is the processor, but adding more of them would not be helpful very much. Increasing this value really is a bad idea, I know now :(.


    // Tried and true method for weather forecasting - random numbers. String weather = (new Random()).Next(2)==0?"rainy":"sunny";

    • 回答としてマーク Uwe82 2012年2月27日 9:18
    2012年2月27日 9:12

すべての返信

  • Hi,

    Since sharepoint search will trim the results based on the user's permissions, i think the file share contents impact the query time. please create a new scope without file share content and give a test.

    Please read following article to re-estimate your search service to decide if you need to increase your hardwares.

    http://technet.microsoft.com/en-us/library/gg750251.aspx

    Also, please check the event logs and uls logs to check if there is any relevant error.

    Regards,

    Seven

    2012年2月27日 9:06
  • We found the reason for this long latencies. It was the refinement panel as I find out through digging into the Searches' verbose logs. The Refinement Panel webpart's setting that tells him how many result items should be included was set to 500 (maximum possible value). Because of this, the Query Server tried to fetch 220,000 rows from the index including metadata after the first wave of 2,400 items. This took a long time.

    After going down to around 150 items, latencies are ok again. Splitting the index (complete index has 3.6 Mio items) would increase a good value to 250, but cannot be done atm. Hardware itself is not a real problem, because IO is ok throughout all systems. Problem is the processor, but adding more of them would not be helpful very much. Increasing this value really is a bad idea, I know now :(.


    // Tried and true method for weather forecasting - random numbers. String weather = (new Random()).Next(2)==0?"rainy":"sunny";

    • 回答としてマーク Uwe82 2012年2月27日 9:18
    2012年2月27日 9:12