All queries in Solr are processed by an active searcher which has a
"read-only", "processed view" of the underlying index.
When a new document is added to the index, that document cannot update the Solr index incrementally and
so to make it visible in the new searches, a new searcher has to be opened. This opening of a new searcher
is a costly operation because:
All queries running on older searcher must complete before new one can take over.
All caches for the older searcher become invalid as they do not reflect new documents.
To improve performance, Solr warms up the new searcher before letting go the older one.
FastLRUCache,
based on a ConcurrentHashMap.
FastLRUCache has faster gets and slower puts in single threaded operation and should be used during high concurrency.
ConcurrentLFUCache,
based on ConcurrentHashMap.
Both FastLRUCache and ConcurrentLFUCache have a CleanerThread to evict entries as they
become least-frequently-used or least-recently-used.
ConcurrentLFUCache,
based on ConcurrentLFUCache but this implementation does not use a separate cleanup thread.
Instead it uses the calling thread itself to do the cleanup when the size of the cache exceeds certain limits.
Cache Implementations in Solr
Filter Cache: Cache used by filters for queries having fq params.
Key for this filter is the value passed for the fq param and the value is the bit vector of matching documents.
Query Result Cache: Cache used to store document-IDs of query-results against their queries.
Document cache: Caches the "stored" fields of documents such that
document ID is the key and group of stored fields in the document is the value.
Again, all of these caches can be fine tuned according to application needs in
solrconfig.xml
Search for the word "cache" in this file to know more about the same.
Got a thought to share or found a bug in the code? We'd love to hear from you: