My initial approach was to use filter cache static fields. However when filter query is used, every query after the first has the same response time as the first. For instance, when cache is enabled in the query under review, response time shoots up to 4-5secs and stays there.
We are using default filter cache settings provided with 4.5.0 distribution. Current Filter Cache stats : lookups:0 hits:0 hitratio:0 inserts:0 evictions:0 size:0 warmupTime:0 cumulative_lookups:17135 cumulative_hits:2465 cumulative_hitratio:0.14 cumulative_inserts:14670 cumulative_evictions:0 I did not find what cumulative_* fields mean here<http://wiki.apache.org/solr/SolrAdminStats> , but it looks like nothing is being cached with fq as hit ratio is 0. Any idea whats happening? On Thu, Mar 6, 2014 at 2:41 PM, Ahmet Arslan <iori...@yahoo.com> wrote: > Hoss, > > Thanks for the correction. I missed the /DAY part and thought as it was > StartDate:[NOW TO NOW+1YEAR] > > Ahmet > > > On Friday, March 7, 2014 12:33 AM, Chris Hostetter < > hossman_luc...@fucit.org> wrote: > > : That did the trick Ahmet. The first response was around 200ms, but the > : subsequent queries were around 2-5ms. > > Are you really sure you want "cache=false" on all of those filters? > > While the "ClientID:4" query may by something that cahnges significantly > enough in every query to not be useful to cache, i suspect you'd find a > lot of value in going ahead and caching those Status:Booked and > StartDate:[NOW/DAY TO NOW/DAY+1YEAR] clauses ... the first query to hit > them might be "slower" but ever query after that should be fairly fast -- > and if you really need them to *always* be fast, configure them as static > newSeracher warming queries (or make sure you have autowarming on. > > It also look like you forgot the "StartDate:" part of your range query in > your last test... > > : &fq={!cache=false cost=50}[NOW/DAY TO NOW/DAY+1YEAR] > > And one finally comment just to make sure it doesn't slip throug hthe > cracks.... > > > : > > Since your range query has NOW in it, it won't be cached > meaningfully. > > this is not applicable. the use of "NOW" in a range query doesn't mean > that it can't be cached -- the problem is anytime you use really precise > dates (or numeric values) that *change* in every query. > > if your range query uses "NOW" as a lower/upper end point, then it calls > in that "really precise dates" situation -- but for this user, who is > specifically rounding his dates to hte nearest day, that advice isn't > really applicable -- the date range queries can be cached & reused for an > entire day. > > > > -Hoss > http://www.lucidworks.com/ > >
