I. Introduction
Solr provides a range of built-in caching to optimize query performance. Solr cache principle mainly involves the following four aspects:
1. The cache size and cache replacement method
From the point of view of the size of the cache, the cache can not be set too large, otherwise it will consume a lot of memory JVM. Solr can all cached objects are stored in memory, it will not overflow written to disk. In order to control the size of the cache, Solr requires a maximum number of cached objects are provided for each cache. When the limit is reached, Solr will use the most recently used [Least Recently Used, LRU replacement method] [or least recently used Least Frequently Used, LFU replacement method] recover a portion of cache space.
Least Recently Used replacement method on the cache size limit reaches the threshold, to determine the order of the cache object is recovered based on the time the cache object was last requested. When the buffer reaches the upper limit, we need to add a new object, LRU replacement method will be replaced with objects in the cache least recently been used. LRU replacement method is the default Solr cache replacement algorithm. Meanwhile, Solr also provides a least recently used replacement method LFU, the method according to the cached object is requested frequency determines the degree of order in the object cache recovered. This substitution method frequently used to give higher priority object cache, rather than the object being requested recently. Solr filters using the LFU cache replacement method. Since the filter is created and stored queries are very resource-intensive, so it is necessary to minimize the size of the filter cache memory, and give applications more frequently used filter priority.
In the cache size that have a common misunderstanding is that the larger the memory space, the larger the cache settings. So do the problems is ineffective once a cache in a commit operation, JVM you need to do a lot of garbage collection work. And close a search will make all the objects in the search cache are invalidated. If no appropriate adjustments to the cache size according to the actual garbage collection, it may cause the server to garbage collection time is too long and cause a long time out of service. Therefore, at this stage the most important thing is to avoid too large a buffer is defined, and you want to cache object periodically recovered.
2. The cache hit rate and cache recovery
Cache hit rate refers to the application cache hit of the number of user requests user requests cent of all proportion the number. Cache hit rate indicates that the cache for application performance optimization of the role. Ideally, we want the cache hit rate as close to 100% [1], low cache hit rate indicates that the cache for performance optimization Solr does not have much effect.
The number of cache recovered indicate how many objects were recovered cache cache replacement method. If the recovered amount is large, it indicates that the maximum cache object is too small application possible settings. Cache cache hit rate and the number of the collection is closely related to the low number of cache recovery often represent a better cache hit ratio.
3. Cache object is invalidated
4. Automatic preheat the new cache