> > * > * > This is not unusual, but there's also not much reason to give this much > memory in your case. This is the cache that is hit when a user pages > through result set. Your numbers would seem to indicate one of two things: > 1> your window is smaller than 2 pages, see solrconfig.xml, > <queryResultWindowSize> > or > 2> your users are rarely going to the next page. > > this cache isn't doing you much good, but then it's also not using that > much in the way of resources. > >
True it is. Although the queryResultWindowSize is 30, I will be reducing it to 4 or so. And yes, we have observed that mostly people don't go beyond the first page > > documentCache > > > > lookups : 17647360 > > hits : 11935609 > > hitratio : 0.67 > > inserts : 5711851 > > evictions : 5707755 > > size : 4096 > > warmupTime : 0 > > cumulative_lookups : 19009142 > > cumulative_hits : 12813630 > > cumulative_hitratio : 0.67 > > cumulative_inserts : 6195512 > > cumulative_evictions : 6187460 > > > > Again, this is actually quite reasonable. This cache > is used to hold document data, and often doesn't have > a great hit ratio. It is necessary though, it saves quite > a bit of disk seeks when servicing a single query. > > > > > fieldValueCache > > > > lookups : 0 > > hits : 0 > > hitratio : 0.00 > > inserts : 0 > > evictions : 0 > > size : 0 > > warmupTime : 0 > > cumulative_lookups : 0 > > cumulative_hits : 0 > > cumulative_hitratio : 0.00 > > cumulative_inserts : 0 > > cumulative_evictions : 0 > > > > Not doing much in the way of faceting, are you? > > No. We don't facet results > > > > filterCache > > > > lookups : 30059278 > > hits : 28813869 > > hitratio : 0.95 > > inserts : 1245744 > > evictions : 1245232 > > size : 512 > > warmupTime : 28005 > > cumulative_lookups : 32155745 > > cumulative_hits : 30845811 > > cumulative_hitratio : 0.95 > > cumulative_inserts : 1309934 > > cumulative_evictions : 1309245 > > > > > > Not a bad hit ratio here, this is where > fq filters are stored. One caution here; > it is better to break out your filter > queries where possible into small chunks. > Rather than write fq=field1:val1 AND field2:val2, > it's better to write fq=field1:val1&fq=field2:val2 > Think of this cache as a map with the query > as the key. If you write the fq the first way above, > subsequent fqs for either half won't use the cache. > That was a great advise. We do use the former approach but going forward we would stick to the latter one. Thanks, Pranav
