solr/solr-ref-guide/src/query-settings-in-solrconfig.adoc - lucene-solr - Git at Google

 = Query Settings in SolrConfig
 // Licensed to the Apache Software Foundation (ASF) under one
 // or more contributor license agreements.  See the NOTICE file
 // distributed with this work for additional information
 // regarding copyright ownership.  The ASF licenses this file
 // to you under the Apache License, Version 2.0 (the
 // "License"); you may not use this file except in compliance
 // with the License.  You may obtain a copy of the License at
 //
 //   http://www.apache.org/licenses/LICENSE-2.0
 //
 // Unless required by applicable law or agreed to in writing,
 // software distributed under the License is distributed on an
 // "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 // KIND, either express or implied.  See the License for the
 // specific language governing permissions and limitations
 // under the License.

 The settings in this section affect the way that Solr will process and respond to queries.

 These settings are all configured in child elements of the `<query>` element in `solrconfig.xml`.

 [source,xml]
 ----
 <query>
   ...
 </query>
 ----

 == Caches

 Solr caches are associated with a specific instance of an Index Searcher, a specific view of an index that doesn't change during the lifetime of that searcher. As long as that Index Searcher is being used, any items in its cache will be valid and available for reuse. By default cached Solr objects do not expire after a time interval; instead, they remain valid for the lifetime of the Index Searcher. Idle time-based expiration can be enabled by using `maxIdleTime` option.

 When a new searcher is opened, the current searcher continues servicing requests while the new one auto-warms its cache. The new searcher uses the current searcher's cache to pre-populate its own. When the new searcher is ready, it is registered as the current searcher and begins handling all new search requests. The old searcher will be closed once it has finished servicing all its requests.

 === Cache Implementations

 In Solr, the following cache implementations are available: recommended `solr.search.CaffeineCache`, and legacy implementations: `solr.search.LRUCache`, `solr.search.FastLRUCache,` and `solr.search.LFUCache`.

 NOTE: `LRUCache`, `LFUCache` and `FastLRUCache` are deprecated and will be removed in Solr 9.0. Users should switch their configurations to use `CaffeineCache` instead.

 The `CaffeineCache` is an implementation backed by the https://github.com/ben-manes/caffeine[Caffeine caching library]. By default it uses a Window TinyLFU (W-TinyLFU) eviction policy, which allows the eviction based on both frequency and recency of use in O(1) time with a small footprint. Generally this cache implementation is recommended over other legacy caches as it usually offers lower memory footprint, higher hit ratio and better multi-threaded performance over legacy caches.

 The acronym LRU stands for Least Recently Used. When an LRU cache fills up, the entry with the oldest last-accessed timestamp is evicted to make room for the new entry. The net effect is that entries that are accessed frequently tend to stay in the cache, while those that are not accessed frequently tend to drop out and will be re-fetched from the index if needed again.

 The `FastLRUCache`, which was introduced in Solr 1.4, is designed to be lock-free, so it is well suited for caches which are hit several times in a request.

 `CaffeineCache`, `LRUCache` and `FastLRUCache` use an auto-warm count that supports both integers and percentages which get evaluated relative to the current size of the cache when warming happens.

 The `LFUCache` refers to the Least Frequently Used cache. This works in a way similar to the LRU cache, except that when the cache fills up, the entry that has been used the least is evicted.

 The Statistics page in the Solr Admin UI will display information about the performance of all the active caches. This information can help you fine-tune the sizes of the various caches appropriately for your particular application. When a Searcher terminates, a summary of its cache usage is also written to the log.

 Each cache has settings to define its initial size (`initialSize`), maximum size (`size`) and number of items to use for during warming (`autowarmCount`). The Caffeine, LRU and FastLRU cache implementations can take a percentage instead of an absolute value for `autowarmCount`.

 Each cache implementation also supports a `maxIdleTime` attribute that controls the automatic eviction of entries that haven't been used for a while. This attribute is expressed in seconds, with the default value of `0` meaning no entries are automatically evicted due to exceeded idle time. Smaller values of this attribute will cause older entries to be evicted quickly, which will reduce cache memory usage but may instead cause thrashing due to a repeating eviction-lookup-miss-insertion cycle of the same entries. Larger values will cause entries to stay around longer, waiting to be reused, at the cost of increased memory usage. Reasonable values, depending on the query volume and patterns, may lie somewhere between 60-3600. Please note that this condition is evaluated synchronously and before other eviction conditions on every entry insertion.

 `CaffeineCache`, `LRUCache` and `FastLRUCache` support a `maxRamMB` attribute that limits the maximum amount of memory a cache may consume. When both `size` and `maxRamMB` limits are specified the behavior will differ among implementations: in `CaffeineCache` the `maxRamMB` limit will take precedence and the `size` limit will be ignored, while in `LRUCache` and `FastLRUCache` both limits will be observed, with entries being evicted whenever any of the limits is reached.

 `FastLRUCache` and `LFUCache` support `showItems` attribute. This is the number of cache items to display in the stats page for the cache. It is for debugging.

 `CaffeineCache` supports the `async` attribute, which determines whether the cache stores direct results (`async=false`, disabled) or whether it will store indirect references to the computation (`async=true`, enabled by default).
 If your queries include child documents or join queries, then async cache must be enabled to function properly.
 Disabling the async option may use slightly less memory per cache entry at the expense of increased CPU.
 The async cache provides most significant improvement with many concurrent queries requesting the same result set that has not yet been cached, as an alternative to larger cache sizes or increased auto-warming counts.
 However, the async cache will not prevent data races for time-limited queries, since those are expected to provide partial results.

 All caches can be disabled using the parameter `enabled` with a value of `false`. Caches can also be disabled on a query-by-query basis with the `cache` parameter, as described in the section <<common-query-parameters.adoc#cache-parameter,cache Parameter>>.

 Details of each cache are described below.

 === filterCache

 This cache is used by `SolrIndexSearcher` for filters (DocSets) for unordered sets of all documents that match a query. The numeric attributes control the number of entries in the cache.

 The most typical way Solr uses the `filterCache` is to cache results of each `fq` search parameter, though there are some other cases as well. Subsequent queries using the same parameter filter query result in cache hits and rapid returns of results. See <<searching.adoc#,Searching>> for a detailed discussion of the `fq` parameter. Another Solr feature using this cache is the `filter(...)` syntax in the default Lucene query parser.

 Solr also uses this cache for faceting when the configuration parameter `facet.method` is set to `fc`. For a discussion of faceting, see <<searching.adoc#,Searching>>.

 The filter cache uses a specialized cache named as FastLRUCache which is optimized for fast concurrent access with the trade-off that writes and evictions are costlier than the LRUCache used for query result cache and document cache.

 [source,xml]
 ----
 <filterCache class="solr.FastLRUCache"
              size="512"
              initialSize="512"
              autowarmCount="128"/>
 ----

 The FastLRUCache used for filter cache also supports a `maxRamMB` parameter which restricts the maximum amount of heap used by this cache. The FastLRUCache only supports evictions by either heap usage or size but not both. Therefore, the `size` parameter is ignored if `maxRamMB` is specified.

 [source,xml]
 ----
 <filterCache class="solr.FastLRUCache"
              maxRamMB="1000"
              autowarmCount="128"/>
 ----

 === queryResultCache

 This cache holds the results of previous searches: ordered lists of document IDs (DocList) based on a query, a sort, and the range of documents requested.

 The `queryResultCache` has an additional (optional) setting to limit the maximum amount of RAM used (`maxRamMB`). This lets you specify the maximum heap size, in megabytes, used by the contents of this cache. When the cache grows beyond this size, oldest accessed queries will be evicted until the heap usage of the cache decreases below the specified limit. If a `size` is specified in addition to `maxRamMB` then both heap usage and maximum size limits are respected.

 [source,xml]
 ----
 <queryResultCache class="solr.LRUCache"
                   size="512"
                   initialSize="512"
                   autowarmCount="128"
                   maxRamMB="1000"/>
 ----

 === documentCache

 This cache holds Lucene Document objects (the stored fields for each document). Since Lucene internal document IDs are transient, this cache is not auto-warmed. The size for the `documentCache` should always be greater than `max_results` times the `max_concurrent_queries`, to ensure that Solr does not need to refetch a document during a request. The more fields you store in your documents, the higher the memory usage of this cache will be.

 [source,xml]
 ----
 <documentCache class="solr.LRUCache"
                size="512"
                initialSize="512"
                autowarmCount="0"/>
 ----

 === User Defined Caches

 You can also define named caches for your own application code to use. You can locate and use your cache object by name by calling the `SolrIndexSearcher` methods `getCache()`, `cacheLookup()` and `cacheInsert()`.

 [source,xml]
 ----
 <cache name="myUserCache" class="solr.LRUCache"
                           size="4096"
                           initialSize="1024"
                           autowarmCount="1024"
                           regenerator="org.mycompany.mypackage.MyRegenerator" />
 ----

 If you want auto-warming of your cache, include a `regenerator` attribute with the fully qualified name of a class that implements `solr.search.CacheRegenerator`. You can also use the `NoOpRegenerator`, which simply repopulates the cache with old items. Define it with the `regenerator` parameter as `regenerator="solr.NoOpRegenerator"`.

 == Query Sizing and Warming

 === maxBooleanClauses

 Sets the maximum number of clauses allowed when parsing a boolean query string.

 This limit only impacts boolean queries specified by a user as part of a query string, and provides per-collection controls on how complex user specified boolean queries can be.  Query strings that specify more clauses than this will result in an error.

 If this per-collection limit is greater than <<format-of-solr-xml#global-maxbooleanclauses,the global `maxBooleanClauses` limit specified in `solr.xml`>> it will have no effect, as that setting also limits the size of user specified boolean queries.

 In default configurations this property uses the value of the `solr.max.booleanClauses` system property if specified.  This is the same system property used in the <<format-of-solr-xml#global-maxbooleanclauses,global `maxBooleanClauses` setting in the default `solr.xml`>> making it easy for Solr administrators to increase both values (in all collections) without needing to search through and update all of their configs.

 [source,xml]
 ----
 <maxBooleanClauses>${solr.max.booleanClauses:1024}</maxBooleanClauses>
 ----

 === enableLazyFieldLoading

 If this parameter is set to true, then fields that are not directly requested will be loaded lazily as needed. This can boost performance if the most common queries only need a small subset of fields, especially if infrequently accessed fields are large in size.

 [source,xml]
 ----
 <enableLazyFieldLoading>true</enableLazyFieldLoading>
 ----

 === useFilterForSortedQuery

 This parameter configures Solr to use a filter to satisfy a search. If the requested sort does not include "score", the `filterCache` will be checked for a filter matching the query. For most situations, this is only useful if the same search is requested often with different sort options and none of them ever use "score".

 [source,xml]
 ----
 <useFilterForSortedQuery>true</useFilterForSortedQuery>
 ----

 === queryResultWindowSize

 Used with the `queryResultCache`, this will cache a superset of the requested number of document IDs. For example, if the a search in response to a particular query requests documents 10 through 19, and `queryWindowSize` is 50, documents 0 through 49 will be cached.

 [source,xml]
 ----
 <queryResultWindowSize>20</queryResultWindowSize>
 ----

 === queryResultMaxDocsCached

 This parameter sets the maximum number of documents to cache for any entry in the `queryResultCache`.

 [source,xml]
 ----
 <queryResultMaxDocsCached>200</queryResultMaxDocsCached>
 ----

 === circuitBreaker

 This set of configurations control the behaviour of circuit breakers.

 [source,xml]
 ----
 <circuitBreaker class="solr.CircuitBreakerManager" enabled="true">
   <!-- All specific configs in this section -->
 </circuitBreaker>
 ----

 To control whether Circuit Breakers are globally enabled, use the "enabled" attribute.

 === Memory Circuit Breaker Settings

 To turn memory circuit breaker on/off, use the following flag:
 [source,xml]
 ----
 <str name="memEnabled">true</str>
 ----

 Memory threshold in percentage for JVM heap usage defined in percentage of maximum heap allocated
 to the JVM (-Xmx). Ideally, this value should be in the range of 75-80% of maximum heap allocated
 to the JVM. The enabled flag can be used to control the specific toggle for this circuit breaker.

 [source,xml]
 ----
 <str name="memThreshold">75</str>
 ----

 === CPU Circuit Breaker Settings

 To control turning on/off this feature, use the following flag:
 [source,xml]
 ----
 <str name="cpuEnabled">true</str>
 ----

 Defines the triggering threshold in terms of the average per minute CPU load. The enabled flag can be used to control the specific toggle for this circuit breaker.

 [source,xml]
 ----
 <str name="cpuThreshold">75</str>
 ----

 === useColdSearcher

 This setting controls whether search requests for which there is not a currently registered searcher should wait for a new searcher to warm up (false) or proceed immediately (true). When set to "false", requests will block until the searcher has warmed its caches.

 [source,xml]
 ----
 <useColdSearcher>false</useColdSearcher>
 ----

 === maxWarmingSearchers

 This parameter sets the maximum number of searchers that may be warming up in the background at any given time. Exceeding this limit will raise an error. For read-only followers, a value of two is reasonable. Leaders should probably be set a little higher.

 [source,xml]
 ----
 <maxWarmingSearchers>2</maxWarmingSearchers>
 ----

 == Query-Related Listeners

 As described in the section on <<Caches>>, new Index Searchers are cached. It's possible to use the triggers for listeners to perform query-related tasks. The most common use of this is to define queries to further "warm" the Index Searchers while they are starting. One benefit of this approach is that field caches are pre-populated for faster sorting.

 Good query selection is key with this type of listener. It's best to choose your most common and/or heaviest queries and include not just the keywords used, but any other parameters such as sorting or filtering requests.

 There are two types of events that can trigger a listener. A `firstSearcher` event occurs when a new searcher is being prepared but there is no current registered searcher to handle requests or to gain auto-warming data from (i.e., on Solr startup). A `newSearcher` event is fired whenever a new searcher is being prepared and there is a current searcher handling requests.

 The (commented out) examples below can be found in the `solrconfig.xml` file of the `sample_techproducts_configs` <<config-sets.adoc#,configset>> included with Solr, and demonstrate using the `solr.QuerySenderListener` class to warm a set of explicit queries:

 [source,xml]
 ----
 <listener event="newSearcher" class="solr.QuerySenderListener">
   <arr name="queries">
   <!--
     <lst><str name="q">solr</str><str name="sort">price asc</str></lst>
     <lst><str name="q">rocks</str><str name="sort">weight asc</str></lst>
    -->
   </arr>
 </listener>

 <listener event="firstSearcher" class="solr.QuerySenderListener">
   <arr name="queries">
     <lst><str name="q">static firstSearcher warming in solrconfig.xml</str></lst>
   </arr>
 </listener>
 ----

 [IMPORTANT]
 ====
 The above code comes from a _sample_ `solrconfig.xml`.

 A key best practice is to modify these defaults before taking your application to production, but please note: while the sample queries are commented out in the section for the "newSearcher", the sample query is not commented out for the "firstSearcher" event.

 There is no point in auto-warming your Index Searcher with the query string "static firstSearcher warming in solrconfig.xml" if that is not relevant to your search application.
 ====
	= Query Settings in SolrConfig
	// Licensed to the Apache Software Foundation (ASF) under one
	// or more contributor license agreements. See the NOTICE file
	// distributed with this work for additional information
	// regarding copyright ownership. The ASF licenses this file
	// to you under the Apache License, Version 2.0 (the
	// "License"); you may not use this file except in compliance
	// with the License. You may obtain a copy of the License at
	//
	// http://www.apache.org/licenses/LICENSE-2.0
	//
	// Unless required by applicable law or agreed to in writing,
	// software distributed under the License is distributed on an
	// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
	// KIND, either express or implied. See the License for the
	// specific language governing permissions and limitations
	// under the License.

	The settings in this section affect the way that Solr will process and respond to queries.

	These settings are all configured in child elements of the `<query>` element in `solrconfig.xml`.

	[source,xml]
	----
	<query>
	...
	</query>
	----

	== Caches

	Solr caches are associated with a specific instance of an Index Searcher, a specific view of an index that doesn't change during the lifetime of that searcher. As long as that Index Searcher is being used, any items in its cache will be valid and available for reuse. By default cached Solr objects do not expire after a time interval; instead, they remain valid for the lifetime of the Index Searcher. Idle time-based expiration can be enabled by using `maxIdleTime` option.

	When a new searcher is opened, the current searcher continues servicing requests while the new one auto-warms its cache. The new searcher uses the current searcher's cache to pre-populate its own. When the new searcher is ready, it is registered as the current searcher and begins handling all new search requests. The old searcher will be closed once it has finished servicing all its requests.

	=== Cache Implementations

	In Solr, the following cache implementations are available: recommended `solr.search.CaffeineCache`, and legacy implementations: `solr.search.LRUCache`, `solr.search.FastLRUCache,` and `solr.search.LFUCache`.

	NOTE: `LRUCache`, `LFUCache` and `FastLRUCache` are deprecated and will be removed in Solr 9.0. Users should switch their configurations to use `CaffeineCache` instead.

	The `CaffeineCache` is an implementation backed by the https://github.com/ben-manes/caffeine[Caffeine caching library]. By default it uses a Window TinyLFU (W-TinyLFU) eviction policy, which allows the eviction based on both frequency and recency of use in O(1) time with a small footprint. Generally this cache implementation is recommended over other legacy caches as it usually offers lower memory footprint, higher hit ratio and better multi-threaded performance over legacy caches.

	The acronym LRU stands for Least Recently Used. When an LRU cache fills up, the entry with the oldest last-accessed timestamp is evicted to make room for the new entry. The net effect is that entries that are accessed frequently tend to stay in the cache, while those that are not accessed frequently tend to drop out and will be re-fetched from the index if needed again.

	The `FastLRUCache`, which was introduced in Solr 1.4, is designed to be lock-free, so it is well suited for caches which are hit several times in a request.

	`CaffeineCache`, `LRUCache` and `FastLRUCache` use an auto-warm count that supports both integers and percentages which get evaluated relative to the current size of the cache when warming happens.

	The `LFUCache` refers to the Least Frequently Used cache. This works in a way similar to the LRU cache, except that when the cache fills up, the entry that has been used the least is evicted.

	The Statistics page in the Solr Admin UI will display information about the performance of all the active caches. This information can help you fine-tune the sizes of the various caches appropriately for your particular application. When a Searcher terminates, a summary of its cache usage is also written to the log.

	Each cache has settings to define its initial size (`initialSize`), maximum size (`size`) and number of items to use for during warming (`autowarmCount`). The Caffeine, LRU and FastLRU cache implementations can take a percentage instead of an absolute value for `autowarmCount`.

	Each cache implementation also supports a `maxIdleTime` attribute that controls the automatic eviction of entries that haven't been used for a while. This attribute is expressed in seconds, with the default value of `0` meaning no entries are automatically evicted due to exceeded idle time. Smaller values of this attribute will cause older entries to be evicted quickly, which will reduce cache memory usage but may instead cause thrashing due to a repeating eviction-lookup-miss-insertion cycle of the same entries. Larger values will cause entries to stay around longer, waiting to be reused, at the cost of increased memory usage. Reasonable values, depending on the query volume and patterns, may lie somewhere between 60-3600. Please note that this condition is evaluated synchronously and before other eviction conditions on every entry insertion.

	`CaffeineCache`, `LRUCache` and `FastLRUCache` support a `maxRamMB` attribute that limits the maximum amount of memory a cache may consume. When both `size` and `maxRamMB` limits are specified the behavior will differ among implementations: in `CaffeineCache` the `maxRamMB` limit will take precedence and the `size` limit will be ignored, while in `LRUCache` and `FastLRUCache` both limits will be observed, with entries being evicted whenever any of the limits is reached.

	`FastLRUCache` and `LFUCache` support `showItems` attribute. This is the number of cache items to display in the stats page for the cache. It is for debugging.

	`CaffeineCache` supports the `async` attribute, which determines whether the cache stores direct results (`async=false`, disabled) or whether it will store indirect references to the computation (`async=true`, enabled by default).
	If your queries include child documents or join queries, then async cache must be enabled to function properly.
	Disabling the async option may use slightly less memory per cache entry at the expense of increased CPU.
	The async cache provides most significant improvement with many concurrent queries requesting the same result set that has not yet been cached, as an alternative to larger cache sizes or increased auto-warming counts.
	However, the async cache will not prevent data races for time-limited queries, since those are expected to provide partial results.

	All caches can be disabled using the parameter `enabled` with a value of `false`. Caches can also be disabled on a query-by-query basis with the `cache` parameter, as described in the section <<common-query-parameters.adoc#cache-parameter,cache Parameter>>.

	Details of each cache are described below.

	=== filterCache

	This cache is used by `SolrIndexSearcher` for filters (DocSets) for unordered sets of all documents that match a query. The numeric attributes control the number of entries in the cache.

	The most typical way Solr uses the `filterCache` is to cache results of each `fq` search parameter, though there are some other cases as well. Subsequent queries using the same parameter filter query result in cache hits and rapid returns of results. See <<searching.adoc#,Searching>> for a detailed discussion of the `fq` parameter. Another Solr feature using this cache is the `filter(...)` syntax in the default Lucene query parser.

	Solr also uses this cache for faceting when the configuration parameter `facet.method` is set to `fc`. For a discussion of faceting, see <<searching.adoc#,Searching>>.

	The filter cache uses a specialized cache named as FastLRUCache which is optimized for fast concurrent access with the trade-off that writes and evictions are costlier than the LRUCache used for query result cache and document cache.

	[source,xml]
	----
	<filterCache class="solr.FastLRUCache"
	size="512"
	initialSize="512"
	autowarmCount="128"/>
	----

	The FastLRUCache used for filter cache also supports a `maxRamMB` parameter which restricts the maximum amount of heap used by this cache. The FastLRUCache only supports evictions by either heap usage or size but not both. Therefore, the `size` parameter is ignored if `maxRamMB` is specified.

	[source,xml]
	----
	<filterCache class="solr.FastLRUCache"
	maxRamMB="1000"
	autowarmCount="128"/>
	----

	=== queryResultCache

	This cache holds the results of previous searches: ordered lists of document IDs (DocList) based on a query, a sort, and the range of documents requested.

	The `queryResultCache` has an additional (optional) setting to limit the maximum amount of RAM used (`maxRamMB`). This lets you specify the maximum heap size, in megabytes, used by the contents of this cache. When the cache grows beyond this size, oldest accessed queries will be evicted until the heap usage of the cache decreases below the specified limit. If a `size` is specified in addition to `maxRamMB` then both heap usage and maximum size limits are respected.

	[source,xml]
	----
	<queryResultCache class="solr.LRUCache"
	size="512"
	initialSize="512"
	autowarmCount="128"
	maxRamMB="1000"/>
	----

	=== documentCache

	This cache holds Lucene Document objects (the stored fields for each document). Since Lucene internal document IDs are transient, this cache is not auto-warmed. The size for the `documentCache` should always be greater than `max_results` times the `max_concurrent_queries`, to ensure that Solr does not need to refetch a document during a request. The more fields you store in your documents, the higher the memory usage of this cache will be.

	[source,xml]
	----
	<documentCache class="solr.LRUCache"
	size="512"
	initialSize="512"
	autowarmCount="0"/>
	----

	=== User Defined Caches

	You can also define named caches for your own application code to use. You can locate and use your cache object by name by calling the `SolrIndexSearcher` methods `getCache()`, `cacheLookup()` and `cacheInsert()`.

	[source,xml]
	----
	<cache name="myUserCache" class="solr.LRUCache"
	size="4096"
	initialSize="1024"
	autowarmCount="1024"
	regenerator="org.mycompany.mypackage.MyRegenerator" />
	----

	If you want auto-warming of your cache, include a `regenerator` attribute with the fully qualified name of a class that implements `solr.search.CacheRegenerator`. You can also use the `NoOpRegenerator`, which simply repopulates the cache with old items. Define it with the `regenerator` parameter as `regenerator="solr.NoOpRegenerator"`.

	== Query Sizing and Warming

	=== maxBooleanClauses

	Sets the maximum number of clauses allowed when parsing a boolean query string.

	This limit only impacts boolean queries specified by a user as part of a query string, and provides per-collection controls on how complex user specified boolean queries can be. Query strings that specify more clauses than this will result in an error.

	If this per-collection limit is greater than <<format-of-solr-xml#global-maxbooleanclauses,the global `maxBooleanClauses` limit specified in `solr.xml`>> it will have no effect, as that setting also limits the size of user specified boolean queries.

	In default configurations this property uses the value of the `solr.max.booleanClauses` system property if specified. This is the same system property used in the <<format-of-solr-xml#global-maxbooleanclauses,global `maxBooleanClauses` setting in the default `solr.xml`>> making it easy for Solr administrators to increase both values (in all collections) without needing to search through and update all of their configs.

	[source,xml]
	----
	<maxBooleanClauses>${solr.max.booleanClauses:1024}</maxBooleanClauses>
	----

	=== enableLazyFieldLoading

	If this parameter is set to true, then fields that are not directly requested will be loaded lazily as needed. This can boost performance if the most common queries only need a small subset of fields, especially if infrequently accessed fields are large in size.

	[source,xml]
	----
	<enableLazyFieldLoading>true</enableLazyFieldLoading>
	----

	=== useFilterForSortedQuery

	This parameter configures Solr to use a filter to satisfy a search. If the requested sort does not include "score", the `filterCache` will be checked for a filter matching the query. For most situations, this is only useful if the same search is requested often with different sort options and none of them ever use "score".

	[source,xml]
	----
	<useFilterForSortedQuery>true</useFilterForSortedQuery>
	----

	=== queryResultWindowSize

	Used with the `queryResultCache`, this will cache a superset of the requested number of document IDs. For example, if the a search in response to a particular query requests documents 10 through 19, and `queryWindowSize` is 50, documents 0 through 49 will be cached.

	[source,xml]
	----
	<queryResultWindowSize>20</queryResultWindowSize>
	----

	=== queryResultMaxDocsCached

	This parameter sets the maximum number of documents to cache for any entry in the `queryResultCache`.

	[source,xml]
	----
	<queryResultMaxDocsCached>200</queryResultMaxDocsCached>
	----

	=== circuitBreaker

	This set of configurations control the behaviour of circuit breakers.

	[source,xml]
	----
	<circuitBreaker class="solr.CircuitBreakerManager" enabled="true">
	<!-- All specific configs in this section -->
	</circuitBreaker>
	----

	To control whether Circuit Breakers are globally enabled, use the "enabled" attribute.

	=== Memory Circuit Breaker Settings

	To turn memory circuit breaker on/off, use the following flag:
	[source,xml]
	----
	<str name="memEnabled">true</str>
	----

	Memory threshold in percentage for JVM heap usage defined in percentage of maximum heap allocated
	to the JVM (-Xmx). Ideally, this value should be in the range of 75-80% of maximum heap allocated
	to the JVM. The enabled flag can be used to control the specific toggle for this circuit breaker.

	[source,xml]
	----
	<str name="memThreshold">75</str>
	----

	=== CPU Circuit Breaker Settings

	To control turning on/off this feature, use the following flag:
	[source,xml]
	----
	<str name="cpuEnabled">true</str>
	----

	Defines the triggering threshold in terms of the average per minute CPU load. The enabled flag can be used to control the specific toggle for this circuit breaker.

	[source,xml]
	----
	<str name="cpuThreshold">75</str>
	----

	=== useColdSearcher

	This setting controls whether search requests for which there is not a currently registered searcher should wait for a new searcher to warm up (false) or proceed immediately (true). When set to "false", requests will block until the searcher has warmed its caches.

	[source,xml]
	----
	<useColdSearcher>false</useColdSearcher>
	----

	=== maxWarmingSearchers

	This parameter sets the maximum number of searchers that may be warming up in the background at any given time. Exceeding this limit will raise an error. For read-only followers, a value of two is reasonable. Leaders should probably be set a little higher.

	[source,xml]
	----
	<maxWarmingSearchers>2</maxWarmingSearchers>
	----

	== Query-Related Listeners

	As described in the section on <<Caches>>, new Index Searchers are cached. It's possible to use the triggers for listeners to perform query-related tasks. The most common use of this is to define queries to further "warm" the Index Searchers while they are starting. One benefit of this approach is that field caches are pre-populated for faster sorting.

	Good query selection is key with this type of listener. It's best to choose your most common and/or heaviest queries and include not just the keywords used, but any other parameters such as sorting or filtering requests.

	There are two types of events that can trigger a listener. A `firstSearcher` event occurs when a new searcher is being prepared but there is no current registered searcher to handle requests or to gain auto-warming data from (i.e., on Solr startup). A `newSearcher` event is fired whenever a new searcher is being prepared and there is a current searcher handling requests.

	The (commented out) examples below can be found in the `solrconfig.xml` file of the `sample_techproducts_configs` <<config-sets.adoc#,configset>> included with Solr, and demonstrate using the `solr.QuerySenderListener` class to warm a set of explicit queries:

	[source,xml]
	----
	<listener event="newSearcher" class="solr.QuerySenderListener">
	<arr name="queries">
	<!--
	<lst><str name="q">solr</str><str name="sort">price asc</str></lst>
	<lst><str name="q">rocks</str><str name="sort">weight asc</str></lst>
	-->
	</arr>
	</listener>

	<listener event="firstSearcher" class="solr.QuerySenderListener">
	<arr name="queries">
	<lst><str name="q">static firstSearcher warming in solrconfig.xml</str></lst>
	</arr>
	</listener>
	----

	[IMPORTANT]
	====
	The above code comes from a _sample_ `solrconfig.xml`.

	A key best practice is to modify these defaults before taking your application to production, but please note: while the sample queries are commented out in the section for the "newSearcher", the sample query is not commented out for the "firstSearcher" event.

	There is no point in auto-warming your Index Searcher with the query string "static firstSearcher warming in solrconfig.xml" if that is not relevant to your search application.
	====