Thanks for the Good information :) Well I haven't had any evictions in any of the caches in years, but the hit ratio is 0.51 in queryResultCache, 0.77 in documentCache, 1.00 in the fieldValueCache, and 0.99 in the filterCache. So in your opinion should the documentCache and queryResultCache use the old way on a single CPU quad core machine?
Also right now I have all caches using the solr.FastLRUCache (tried with both the cleanupThread = false or true) and I have noticed some queries that are taking 53 ms on a freshly warmed new searcher (when nothing else is querying the slave), but when the slave is busy the same query, that should be using the caches, is sometimes taking 8 secs? Any thoughts? Thanks Robert. Yonik Seeley-2 wrote: > > 2009/6/4 Noble Paul നോബിള് नोब्ळ् <noble.p...@corp.aol.com>: >> FastLRUCache is designed to be lock free so it is well suited for >> caches which are hit several times in a request. I guess there is no >> harm in using FastLRUCache across all the caches. > > Gets are cheaper, but evictions are more expensive. If the cache hit > rate is low, the old synchronized cache may be faster, unless you have > a ton of CPUs... not sure where the crossover point is though. > > -Yonik > http://www.lucidimagination.com > > -- View this message in context: http://www.nabble.com/Which-caches-should-use-the-solr.FastLRUCache-tp23860182p23874898.html Sent from the Solr - User mailing list archive at Nabble.com.
