On Thu, Jun 4, 2009 at 11:29 PM, Robert Purdy <rdpu...@gmail.com> wrote: > > 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?
This overhead may not be because of the cache itself. Some queries are definitely missing the cache and they are likely to take time. if cleanupThread=true, then no eviction should take more time > > 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. > > -- ----------------------------------------------------- Noble Paul | Principal Engineer| AOL | http://aol.com
