Q: We are getting a zero hit rate on queryResultsCache. Some of the developers tried executing a really simple query (“Canada”) several times on one of the Solr servers, but the queryResultsCache hit rate stayed at zero. There is something wrong here that we need help with. The reason we are concerned with the zero hit rate QueryResultCache is that we have a large number of queries that are executed frequently.
A: The reason why you have such bad hitratio for the queryResultCache (and probably, the filter cache could also be much better) is that for every query you are appending a filter in the solrconfig) like:
<str name="fq">activatedate:[* TO NOW] AND expiredate:[NOW TO *]</str>
In this query, you are using "NOW". "NOW" gets translated to a date with millisecond precision before running the query. This means that the same user query executed with one millisecond of difference will create a different query, and therefore it won't hit the queryResultCache. Also, this filter won't hit the filterCache either for the same reason.
you can truncate the "NOW" so that it doesn't contain values to the millisecond by adding a slash and the unit, for example:
The bigger the unit, the hitratio will grow even more, but the value set here really depends on your business goals with this field
Note1: The fact that the filter is being appended by the solrconfig instead of explicitly by the client application makes no difference here, it may make the problem more difficult to find, but the same issue would reproduce if the filter is added by the client application.
Note2: If you are using NRT with very high soft commit frequency (1 second for example) you can see a similar problem, even if nor the query or any of the filters contain a "NOW" value. In this case the reason will be that with every search you are hitting a different SolrSearcher. Remember that caches life-cycle is the same as the Searcher's.