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.
