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
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.
In Solr, the following cache implementations are available: recommended
solr.search.CaffeineCache, and legacy implementations:
FastLRUCache are deprecated and will be removed in Solr 9.0. Users should switch their configurations to use
CaffeineCache is an implementation backed by the 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.
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.
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.
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
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.
FastLRUCache support a
maxRamMB attribute that limits the maximum amount of memory a cache may consume. When both
maxRamMB limits are specified the behavior will differ among implementations: in
maxRamMB limit will take precedence and the
size limit will be ignored, while in
FastLRUCache both limits will be observed, with entries being evicted whenever any of the limits is reached.
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 cache Parameter.
Details of each cache are described below.
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(…) 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.
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.
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.