You say "all of my queries are based upon fq"? Why? How unique are they?
Remember, for each fq value, it could end up storing one bit per
document in your index. If you have 8m documents, you could end up with
a cache usage of 1Mb, for that query alone!
Filter queries are primarily designed for queries that are repeated,
e.g.: category:sport, where caching gives some advantage.
If all of your queries are unique, then move them to the q= parameter,
or make them fq={!cache=false}, otherwise you will waste memory storing
cached values that are never used, and CPU building and then destroying
those cached entries.
Upayavira
On Wed, Aug 19, 2015, at 02:25 PM, wwang525 wrote:
> Hi Erick,
>
> All my queries are based on fq (filter query). I have to send the
> randomly
> generated queries to warm up low level lucene cache.
>
> I went to the more tedious way to warm up low level cache without
> utilizing
> the three caches by turning off the three caches (set values to zero).
> Then,
> I send 800 randomly generated request to Solr. The RAM jumped from 500MB
> to
> 2.5G, and stayed there.
>
> Then, I test individual queries against Solr. This time, I got very close
> response time when I requested the first time, second time, or third
> time.
>
> The results:
>
> (1) average response time: 803 ms with only one request having a response
> time >1 second (1042 ms)
> (2) the majority of the time was spent on query, and not on faceting
> (730/803 = 90%)
>
> So the query is the bottleneck.
>
> I also have an interesting finding: it looks like the fq query works
> better
> with integer type. I created string type for two properties: DateDep and
> Duration since the definition of docValues=true for integer type did not
> work with faceted search. There was a time I accidentally used filter
> query
> with the string type property and I found the query performance degraded
> quite a lot.
>
> Is it generally true that fq works better with integer type ?
>
> If this is the case, I could create two integer type properties for two
> other fq to check if I can boost the performance.
>
> Thanks
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Is-it-a-good-query-performance-with-this-data-size-tp4223699p4223920.html
> Sent from the Solr - User mailing list archive at Nabble.com.
