{"id":1495,"date":"2020-08-20T17:46:11","date_gmt":"2020-08-20T17:46:11","guid":{"rendered":"https:\/\/www.aeologic.com\/blog\/?p=1495"},"modified":"2020-08-20T17:48:16","modified_gmt":"2020-08-20T17:48:16","slug":"solr-caches-ultimate-solr-guide","status":"publish","type":"post","link":"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/","title":{"rendered":"Solr caches – Ultimate Solr Guide"},"content":{"rendered":"\n

The settings in this section affect the way that Solr will process and respond to queries.<\/p>\n\n\n\n

These settings are all configured in child elements of the <query><\/code> element in solrconfig.xml<\/code>.<\/p>\n\n\n\n

<query>\n  ...\n<\/query><\/code><\/pre>\n\n\n\n
Caches<\/h2>\n\n\n\n
Solr caches are associated with a specific instance of an Index Searcher, a specific view of an index that doesn\u2019t 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. Caching in Solr differs from caching in many other applications in that cached Solr objects do not expire after a time interval; instead, they remain valid for the lifetime of the Index Searcher.<\/p>\n\n\n\n
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\u2019s 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.<\/p>\n\n\n\n
In Solr, there are three cache implementations: solr.search.LRUCache<\/code>, solr.search.FastLRUCache,<\/code> and solr.search.LFUCache<\/code> .<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
The FastLRUCache<\/code>, 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.<\/p>\n\n\n\n
Both LRUCache<\/code> and FastLRUCache<\/code> 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.<\/p>\n\n\n\n
The LFUCache<\/code> 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Each cache has settings to define its initial size (initialSize<\/code>), maximum size (size<\/code>) and number of items to use for during warming (autowarmCount<\/code>). The LRU and FastLRU cache implementations can take a percentage instead of an absolute value for autowarmCount<\/code>.<\/p>\n\n\n\n
FastLRUCache and LFUCache support showItems<\/code> attribute. This is the number of cache items to display in the stats page for the cache. It is for debugging.<\/p>\n\n\n\n
Details of each cache are described below.<\/p>\n\n\n\n
filterCache<\/code><\/h3>\n\n\n\n
This cache is used by SolrIndexSearcher<\/code> for filters (DocSets) for unordered sets of all documents that match a query. The numeric attributes control the number of entries in the cache.<\/p>\n\n\n\n
The most typical way Solr uses the filterCache<\/code> is to cache results of each fq<\/code> 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<\/a> for a detailed discussion of the fq<\/code> parameter. Another Solr feature using this cache is the filter(\u2026\u200b)<\/code> syntax in the default Lucene query parser.<\/p>\n\n\n\n
Solr also uses this cache for faceting when the configuration parameter facet.method<\/code> is set to fc<\/code>. For a discussion of faceting, see Searching<\/a>.<\/p>\n\n\n\n
<filterCache class=\"solr.LRUCache\"\n             size=\"512\"\n             initialSize=\"512\"\n             autowarmCount=\"128\"\/><\/code><\/pre>\n\n\n\n
queryResultCache<\/code><\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
The queryResultCache<\/code> has an additional (optional) setting to limit the maximum amount of RAM used (maxRamMB<\/code>). 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.<\/p>\n\n\n\n
<queryResultCache class=\"solr.LRUCache\"\n                  size=\"512\"\n                  initialSize=\"512\"\n                  autowarmCount=\"128\"\n                  maxRamMB=\"1000\"\/><\/code><\/pre>\n\n\n\n
documentCache<\/code><\/h3>\n\n\n\n
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<\/code> should always be greater than max_results<\/code> times the max_concurrent_queries<\/code>, 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.<\/p>\n\n\n\n
<documentCache class=\"solr.LRUCache\"\n               size=\"512\"\n               initialSize=\"512\"\n               autowarmCount=\"0\"\/><\/code><\/pre>\n\n\n\n
User Defined Caches<\/h3>\n\n\n\n
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<\/code> methods getCache()<\/code>, cacheLookup()<\/code> and cacheInsert()<\/code>.<\/p>\n\n\n\n
<cache name=\"myUserCache\" class=\"solr.LRUCache\"\n                          size=\"4096\"\n                          initialSize=\"1024\"\n                          autowarmCount=\"1024\"\n                          regenerator=\"org.mycompany.mypackage.MyRegenerator\" \/><\/code><\/pre>\n\n\n\n
If you want auto-warming of your cache, include a regenerator<\/code> attribute with the fully qualified name of a class that implements solr.search.CacheRegenerator<\/code>. You can also use the NoOpRegenerator<\/code>, which simply repopulates the cache with old items. Define it with the regenerator<\/code> parameter as`: regenerator=”solr.NoOpRegenerator”`.<\/p>\n\n\n\n
Query Sizing and Warming<\/h2>\n\n\n\n
maxBooleanClauses<\/code><\/h3>\n\n\n\n
This sets the maximum number of clauses allowed in a boolean query. This can affect range or prefix queries that expand to a query with a large number of boolean terms. If this limit is exceeded, an exception is thrown.<\/p>\n\n\n\n
<maxBooleanClauses>1024<\/maxBooleanClauses><\/code><\/pre>\n\n\n\n
<\/td>This option modifies a global property that effects all Solr cores. If multiple solrconfig.xml<\/code> files disagree on this property, the value at any point in time will be based on the last Solr core that was initialized.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
enableLazyFieldLoading<\/code><\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
<enableLazyFieldLoading>true<\/enableLazyFieldLoading><\/code><\/pre>\n\n\n\n
useFilterForSortedQuery<\/code><\/h3>\n\n\n\n
This parameter configures Solr to use a filter to satisfy a search. If the requested sort does not include “score”, the filterCache<\/code> 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”.<\/p>\n\n\n\n
<useFilterForSortedQuery>true<\/useFilterForSortedQuery><\/code><\/pre>\n\n\n\n
queryResultWindowSize<\/code><\/h3>\n\n\n\n
Used with the queryResultCache<\/code>, 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<\/code> is 50, documents 0 through 49 will be cached.<\/p>\n\n\n\n
<queryResultWindowSize>20<\/queryResultWindowSize><\/code><\/pre>\n\n\n\n
queryResultMaxDocsCached<\/code><\/h3>\n\n\n\n
This parameter sets the maximum number of documents to cache for any entry in the queryResultCache<\/code>.<\/p>\n\n\n\n
<queryResultMaxDocsCached>200<\/queryResultMaxDocsCached><\/code><\/pre>\n\n\n\n
useColdSearcher<\/code><\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
<useColdSearcher>false<\/useColdSearcher><\/code><\/pre>\n\n\n\n
maxWarmingSearchers<\/code><\/h3>\n\n\n\n
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 slaves, a value of two is reasonable. Masters should probably be set a little higher.<\/p>\n\n\n\n
<maxWarmingSearchers>2<\/maxWarmingSearchers><\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"
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. Caches Solr caches are associated with a specific instance of an Index Searcher, a specific view of an index that doesn\u2019t 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. Caching in Solr differs from caching in many other applications in that cached Solr objects do not expire after a time interval; instead, they remain valid for the lifetime of the Index Searcher. 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\u2019s 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. In Solr, there are three cache implementations: solr.search.LRUCache, solr.search.FastLRUCache, and solr.search.LFUCache . 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. Both 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 LRU and FastLRU cache implementations can take a percentage instead of an absolute value for autowarmCount. 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. 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 for a detailed discussion of the fq parameter. Another Solr feature using this cache is the filter(\u2026\u200b) 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. 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. 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. 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(). 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 This sets the maximum number of clauses allowed in a boolean query. This can affect range or prefix queries that expand to a query with a large number of boolean terms. If this limit is exceeded, an exception is thrown. This option modifies a global property that effects all Solr cores. If multiple solrconfig.xml files disagree on this property, the value at any point in time will be based on the last Solr core that was initialized. 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. 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”. 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 […]<\/p>\n","protected":false},"author":3,"featured_media":1498,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[41],"tags":[138,7,137,91,139],"class_list":["post-1495","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-solr","tag-cache","tag-solr","tag-solr-cache","tag-solr-index","tag-ultimate-solr-indexing"],"yoast_head":"\nSolr caches - Ultimate Solr Guide - Aeologic Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Solr caches - Ultimate Solr Guide - Aeologic Blog\" \/>\n<meta property=\"og:description\" content=\"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. Caches Solr caches are associated with a specific instance of an Index Searcher, a specific view of an index that doesn\u2019t 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. Caching in Solr differs from caching in many other applications in that cached Solr objects do not expire after a time interval; instead, they remain valid for the lifetime of the Index Searcher. 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\u2019s 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. In Solr, there are three cache implementations: solr.search.LRUCache, solr.search.FastLRUCache, and solr.search.LFUCache . 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. Both 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 LRU and FastLRU cache implementations can take a percentage instead of an absolute value for autowarmCount. 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. 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 for a detailed discussion of the fq parameter. Another Solr feature using this cache is the filter(\u2026\u200b) 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. 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. 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. 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(). 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 This sets the maximum number of clauses allowed in a boolean query. This can affect range or prefix queries that expand to a query with a large number of boolean terms. If this limit is exceeded, an exception is thrown. This option modifies a global property that effects all Solr cores. If multiple solrconfig.xml files disagree on this property, the value at any point in time will be based on the last Solr core that was initialized. 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. 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”. 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 […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/\" \/>\n<meta property=\"og:site_name\" content=\"Aeologic Blog\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/AeoLogicTech\/\" \/>\n<meta property=\"article:published_time\" content=\"2020-08-20T17:46:11+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2020-08-20T17:48:16+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/08\/Caches-in-solr.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1080\" \/>\n\t<meta property=\"og:image:height\" content=\"622\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Manoj Kumar\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@aeologictech\" \/>\n<meta name=\"twitter:site\" content=\"@aeologictech\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Manoj Kumar\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"7 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":[\"Article\",\"BlogPosting\"],\"@id\":\"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/\"},\"author\":{\"name\":\"Manoj Kumar\",\"@id\":\"https:\/\/www.aeologic.com\/blog\/#\/schema\/person\/13549984ba8e5f441cc733ed20d7daa4\"},\"headline\":\"Solr caches – Ultimate Solr Guide\",\"datePublished\":\"2020-08-20T17:46:11+00:00\",\"dateModified\":\"2020-08-20T17:48:16+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/\"},\"wordCount\":1181,\"publisher\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/#organization\"},\"image\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/08\/Caches-in-solr.png\",\"keywords\":[\"cache\",\"solr\",\"solr cache\",\"solr index\",\"ultimate solr indexing\"],\"articleSection\":[\"Solr\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/\",\"url\":\"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/\",\"name\":\"Solr caches - Ultimate Solr Guide - Aeologic Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/08\/Caches-in-solr.png\",\"datePublished\":\"2020-08-20T17:46:11+00:00\",\"dateModified\":\"2020-08-20T17:48:16+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/#primaryimage\",\"url\":\"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/08\/Caches-in-solr.png\",\"contentUrl\":\"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/08\/Caches-in-solr.png\",\"width\":1080,\"height\":622},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.aeologic.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Solr caches – Ultimate Solr Guide\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.aeologic.com\/blog\/#website\",\"url\":\"https:\/\/www.aeologic.com\/blog\/\",\"name\":\"Aeologic Blog\",\"description\":\"Aeologic\",\"publisher\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.aeologic.com\/blog\/?s={search_term_string}\"},\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.aeologic.com\/blog\/#organization\",\"name\":\"AeoLogic Technologies\",\"url\":\"https:\/\/www.aeologic.com\/blog\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.aeologic.com\/blog\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2022\/05\/new-logo-aeo.jpg\",\"contentUrl\":\"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2022\/05\/new-logo-aeo.jpg\",\"width\":385,\"height\":162,\"caption\":\"AeoLogic Technologies\"},\"image\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/www.facebook.com\/AeoLogicTech\/\",\"https:\/\/x.com\/aeologictech\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.aeologic.com\/blog\/#\/schema\/person\/13549984ba8e5f441cc733ed20d7daa4\",\"name\":\"Manoj Kumar\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.aeologic.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/24ce77602da5eb5715d74a95733f6c7548e2af73f5a493f9bc0bf55f611d025e?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/24ce77602da5eb5715d74a95733f6c7548e2af73f5a493f9bc0bf55f611d025e?s=96&d=mm&r=g\",\"caption\":\"Manoj Kumar\"},\"description\":\"Manoj Kumar is a seasoned Digital Marketing Manager and passionate Tech Blogger with deep expertise in SEO, AI trends, and emerging digital technologies. He writes about innovative solutions that drive growth and transformation across industry. Featured on - YOURSTORY | TECHSLING | ELEARNINGINDUSTRY | DATASCIENCECENTRAL | TIMESOFINDIA | MEDIUM | DATAFLOQ\",\"sameAs\":[\"https:\/\/www.aeologic.com\/\",\"https:\/\/www.linkedin.com\/in\/manoj-kumar-rajput\/\"],\"url\":\"https:\/\/www.aeologic.com\/blog\/author\/manoj\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Solr caches - Ultimate Solr Guide - Aeologic Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/","og_locale":"en_US","og_type":"article","og_title":"Solr caches - Ultimate Solr Guide - Aeologic Blog","og_description":"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. Caches Solr caches are associated with a specific instance of an Index Searcher, a specific view of an index that doesn\u2019t 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. Caching in Solr differs from caching in many other applications in that cached Solr objects do not expire after a time interval; instead, they remain valid for the lifetime of the Index Searcher. 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\u2019s 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. In Solr, there are three cache implementations: solr.search.LRUCache, solr.search.FastLRUCache, and solr.search.LFUCache . 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. Both 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 LRU and FastLRU cache implementations can take a percentage instead of an absolute value for autowarmCount. 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. 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 for a detailed discussion of the fq parameter. Another Solr feature using this cache is the filter(\u2026\u200b) 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. 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. 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. 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(). 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 This sets the maximum number of clauses allowed in a boolean query. This can affect range or prefix queries that expand to a query with a large number of boolean terms. If this limit is exceeded, an exception is thrown. This option modifies a global property that effects all Solr cores. If multiple solrconfig.xml files disagree on this property, the value at any point in time will be based on the last Solr core that was initialized. 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. 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”. 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 […]","og_url":"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/","og_site_name":"Aeologic Blog","article_publisher":"https:\/\/www.facebook.com\/AeoLogicTech\/","article_published_time":"2020-08-20T17:46:11+00:00","article_modified_time":"2020-08-20T17:48:16+00:00","og_image":[{"width":1080,"height":622,"url":"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/08\/Caches-in-solr.png","type":"image\/png"}],"author":"Manoj Kumar","twitter_card":"summary_large_image","twitter_creator":"@aeologictech","twitter_site":"@aeologictech","twitter_misc":{"Written by":"Manoj Kumar","Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":["Article","BlogPosting"],"@id":"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/#article","isPartOf":{"@id":"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/"},"author":{"name":"Manoj Kumar","@id":"https:\/\/www.aeologic.com\/blog\/#\/schema\/person\/13549984ba8e5f441cc733ed20d7daa4"},"headline":"Solr caches – Ultimate Solr Guide","datePublished":"2020-08-20T17:46:11+00:00","dateModified":"2020-08-20T17:48:16+00:00","mainEntityOfPage":{"@id":"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/"},"wordCount":1181,"publisher":{"@id":"https:\/\/www.aeologic.com\/blog\/#organization"},"image":{"@id":"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/#primaryimage"},"thumbnailUrl":"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/08\/Caches-in-solr.png","keywords":["cache","solr","solr cache","solr index","ultimate solr indexing"],"articleSection":["Solr"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/","url":"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/","name":"Solr caches - Ultimate Solr Guide - Aeologic Blog","isPartOf":{"@id":"https:\/\/www.aeologic.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/#primaryimage"},"image":{"@id":"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/#primaryimage"},"thumbnailUrl":"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/08\/Caches-in-solr.png","datePublished":"2020-08-20T17:46:11+00:00","dateModified":"2020-08-20T17:48:16+00:00","breadcrumb":{"@id":"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/#primaryimage","url":"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/08\/Caches-in-solr.png","contentUrl":"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/08\/Caches-in-solr.png","width":1080,"height":622},{"@type":"BreadcrumbList","@id":"https:\/\/www.aeologic.com\/blog\/solr-caches-ultimate-solr-guide\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.aeologic.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Solr caches – Ultimate Solr Guide"}]},{"@type":"WebSite","@id":"https:\/\/www.aeologic.com\/blog\/#website","url":"https:\/\/www.aeologic.com\/blog\/","name":"Aeologic Blog","description":"Aeologic","publisher":{"@id":"https:\/\/www.aeologic.com\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.aeologic.com\/blog\/?s={search_term_string}"},"query-input":"required name=search_term_string"}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.aeologic.com\/blog\/#organization","name":"AeoLogic Technologies","url":"https:\/\/www.aeologic.com\/blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.aeologic.com\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2022\/05\/new-logo-aeo.jpg","contentUrl":"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2022\/05\/new-logo-aeo.jpg","width":385,"height":162,"caption":"AeoLogic Technologies"},"image":{"@id":"https:\/\/www.aeologic.com\/blog\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/AeoLogicTech\/","https:\/\/x.com\/aeologictech"]},{"@type":"Person","@id":"https:\/\/www.aeologic.com\/blog\/#\/schema\/person\/13549984ba8e5f441cc733ed20d7daa4","name":"Manoj Kumar","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.aeologic.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/24ce77602da5eb5715d74a95733f6c7548e2af73f5a493f9bc0bf55f611d025e?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/24ce77602da5eb5715d74a95733f6c7548e2af73f5a493f9bc0bf55f611d025e?s=96&d=mm&r=g","caption":"Manoj Kumar"},"description":"Manoj Kumar is a seasoned Digital Marketing Manager and passionate Tech Blogger with deep expertise in SEO, AI trends, and emerging digital technologies. He writes about innovative solutions that drive growth and transformation across industry. Featured on - YOURSTORY | TECHSLING | ELEARNINGINDUSTRY | DATASCIENCECENTRAL | TIMESOFINDIA | MEDIUM | DATAFLOQ","sameAs":["https:\/\/www.aeologic.com\/","https:\/\/www.linkedin.com\/in\/manoj-kumar-rajput\/"],"url":"https:\/\/www.aeologic.com\/blog\/author\/manoj\/"}]}},"_links":{"self":[{"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/posts\/1495","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/comments?post=1495"}],"version-history":[{"count":0,"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/posts\/1495\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/media\/1498"}],"wp:attachment":[{"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/media?parent=1495"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/categories?post=1495"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/tags?post=1495"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}