SOLR 在第一个方面查询时很慢，但在以后的查询中相当快

我试图找出为什么我的 SOLR (4.1 ) 实例对于方面查询非常慢。 索引大约有200M文档，服务器有64GB RAM。

我的查询如下所示：

q=CampaignId:1462%0ASourceDateUtc:[2014-01-01T00:00:00.000Z TO 2014-01-30T00:00:00.000Z]
&wt=xml&indent=true&rows=0
&facet=true&facet.field=UserName&facet.mincount=10&facet.method=fc

第一次命中大约需要 6 分钟，但是当结果返回时，我使用相同的查询再次搜索或稍微更改 SourceDateUtc 中的范围，它运行得相当快。

这是我的 solrconfig.xml （查询部分）

<query>
  <!-- Cache used by SolrIndexSearcher for filters (DocSets),
         unordered sets of *all* documents that match a query.
         When a new searcher is opened, its caches may be prepopulated
         or "autowarmed" using data from caches in the old searcher.
         autowarmCount is the number of items to prepopulate.  For LRUCache,
         the autowarmed items will be the most recently accessed items.
       Parameters:
         class - the SolrCache implementation (currently only LRUCache)
         size - the maximum number of entries in the cache
         initialSize - the initial capacity (number of entries) of
           the cache.  (seel java.util.HashMap)
         autowarmCount - the number of entries to prepopulate from
           and old cache.

    <filterCache
      class="solr.LRUCache"
      size="1024"
      initialSize="512"
      autowarmCount="0"/>-->

   <!-- queryResultCache caches results of searches - ordered lists of
         document ids (DocList) based on a query, a sort, and the range
         of documents requested.  -->
    <queryResultCache
      class="solr.LRUCache"
      size="10000"
      initialSize="512"
      autowarmCount="0"/>

  <!-- documentCache caches Lucene Document objects (the stored fields for each document).
       Since Lucene internal document ids are transient, this cache will not be autowarmed.  -->
    <documentCache
      class="solr.LRUCache"
      size="1024"
      initialSize="512"
      autowarmCount="0"/>

    <!-- Example of a generic cache.  These caches may be accessed by name
         through SolrIndexSearcher.getCache().cacheLookup(), and cacheInsert().
         The purpose is to enable easy caching of user/application level data.
         The regenerator argument should be specified as an implementation
         of solr.search.CacheRegenerator if autowarming is desired.  -->
    <!--
    <cache name="myUserCache"
      class="solr.LRUCache"
      size="4096"
      initialSize="1024"
      autowarmCount="1024"
      regenerator="org.mycompany.mypackage.MyRegenerator"
      />
    -->

    <!-- An optimization that attempts to use a filter to satisfy a search.
         If the requested sort does not include a score, then the filterCache
         will be checked for a filter matching the query.  If found, the filter
         will be used as the source of document ids, and then the sort will be
         applied to that.
      -->
    <useFilterForSortedQuery>true</useFilterForSortedQuery>

    <!-- An optimization for use with the queryResultCache.  When a search
         is requested, a superset of the requested number of document ids
         are collected.  For example, of a search for a particular query
         requests matching documents 10 through 19, and queryWindowSize is 50,
         then documents 0 through 50 will be collected and cached. Any further
         requests in that range can be satisfied via the cache.
    -->
    <queryResultWindowSize>100</queryResultWindowSize>

    <!-- This entry enables an int hash representation for filters (DocSets)
         when the number of items in the set is less than maxSize. For smaller
         sets, this representation is more memory efficient, more efficient to
         iterate over, and faster to take intersections.
     -->
    <HashDocSet maxSize="3000" loadFactor="0.75"/>


    <!-- boolToFilterOptimizer converts boolean clauses with zero boost
         cached filters if the number of docs selected by the clause exceeds the
         threshold (represented as a fraction of the total index)
    -->
    <boolTofilterOptimizer enabled="true" cacheSize="32" threshold=".05"/>

    <!-- Lazy field loading will attempt to read only parts of documents on disk that are
         requested.  Enabling should be faster if you aren't retrieving all stored fields.
    -->
    <enableLazyFieldLoading>false</enableLazyFieldLoading>

    <!-- Use Cold Searcher

         If a search request comes in and there is no current
         registered searcher, then immediately register the still
         warming searcher and use it.  If "false" then all requests
         will block until the first searcher is done warming.
    -->
    <useColdSearcher>true</useColdSearcher>

</query>

我也尝试启用filterCache，但没有帮助。

Thanks.

可能是热身问题。预热字段缓存(facet.method=fc)对于solr有效工作非常重要。如果您尚未配置预热查询，请考虑将方面查询（如示例中所示）添加到 solrconfig.xml 中的 newsearcher 和 firstsearcher 部分。

http://wiki.apache.org/solr/SolrConfigXml#A.22Query.22_Related_Event_Listeners

<listener event="firstSearcher" class="solr.QuerySenderListener">
      <arr name="queries">
        <lst> <str name="q">*:*</str>
              <str name="start">0</str>
              <str name="rows">10</str>
              <str name="facet">true</str>
              <str name="facet.field">UserName</str>
              <str name="facet.mincount">10</str>
              <str name="facet.method">fc</str>
        </lst>
      </arr>
</listener>

您可能还想关闭 useColdSearher

<useColdSearcher>true</useColdSearcher>

进一步阅读：

Solr 中良好的自动预热查询的要素是什么？它们是如何工作的？

http://wiki.apache.org/solr/SolrFacetingOverview