: 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/
