It's actually unlikely that increasing the documentCache will
help materially. It's primarily so various components won't
have to fetch the documents off disk for a _single_ request.
I've heard some anecdotal evidence that it helps in some situations,
but that's been rare in my experience.
Your filterCache is a bomb waiting to go off.
Each filterCache entry can be up to maxDoc/8 bytes long, so if you let
you don't re-open searchers (thus causing it to flush), that cache
could eventually grow to on the order of 28G. The autowarm count is also quite
high. I'd start by knocking these back a _lot_. Also, look at why
your hit ratio is this low. If you have a lot of fq clauses that you _know_
aren't going to be re-used, use {!cache=false}. If you are using
NOW, that's an anti-pattern, see:
http://lucidworks.com/blog/date-math-now-and-filter-queries/
queryResultCache is largely used for paging, having 0 hits
is a good thing for stress tests since it insures that you're not
getting false stats because of this. But there's no good reason
to have this over 16K max. It will be significantly smaller than
the filterCache, but still a waste. Again, the autowarm count is
very high. Taking it back to 32 or so is where I'd start.
bq: especially after a short period of time of the test.
right, this is due to filling up the lower-level caches. If you haven't
restarted your system then the autowarming will fill them up. But you
can also specify newSearcher and firstSearcher queries to do the same
thing at far less expense than executing 256 queries every time you
open a new searcher.
In summary, your settings are far too high for most people, I'd start
by examining the usage rather than making them bigger.
Best,
Erick
On Thu, Jul 9, 2015 at 8:48 AM, wwang525 <wwang...@gmail.com> wrote:
> Hi All,
>
> I did a load test with a total of 800 requests (at 40 concurrent requests
> per second) to be executed against Solr index with 14 M records. Performance
> was good (< 1 second) especially after a short period of time of the test.
> BTW, the second round of load test was even better.
>
> The local machine has a free memory of about 15 G during the load test
>
> I observed the following from the stats page:
>
> (1) documentCache reached the configured size for documentCache with a hit
> ratio of 0.66
> (2) filterCache has 2519 hits with a hit ratio of 0.63. The size is 1465
> (less than a configured size: 16384)
> (3) queryResultCache has a hit ratio of 0
> (4) fieldValueCache has a hit ratio of 0
>
> The following are the cache configuration in solrconfig.xml
>
> <documentCache
> class="solr.LRUCache"
> size="16384"
> initialSize="512"
> autowarmCount="0"/>
>
>
> <filterCache
> class="solr.LRUCache"
> size="16384"
> initialSize="4096"
> autowarmCount="256"/>
>
>
> <queryResultCache
> class="solr.LRUCache"
> size="16384"
> initialSize="4096"
> autowarmCount="256"/>
>
> It looks like I need to increase the size of documentCache. The hit ratio of
> zero for queryResultCache and fieldValueCache was surprising (zero). Is it
> possible that this is due to randomly generated requests?
>
> What are some guideline in tuning the cache parameter?
>
> Thanks
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/How-to-determine-cache-setting-in-Solr-Search-Instance-tp4216562.html
> Sent from the Solr - User mailing list archive at Nabble.com.
