Pardon my typo. I meant 1000ms in my last mail.
Thanks,
-Vijay
On Mon, Mar 10, 2014 at 4:22 PM, Vijay Kokatnur wrote:
> Thanks Erick. The links you provided are invaluable.
>
> Here are our commit settings. Since we have NRT search, softCommit is set
> to 1000s which explains why cache is co
Thanks Erick. The links you provided are invaluable.
Here are our commit settings. Since we have NRT search, softCommit is set
to 1000s which explains why cache is constantly invalidated.
60
false
1000
With constant cache invalidation it becom
Maybe I spoke too soon.
The second and third filter parameter *fq={!cache=false cost=50}ClientID:4*and
*fq={!cache=false cost=150}StartDate:[NOW/DAY TO NOW/DAY+1YEAR] *above are
not getting executed, unless I make it the first parameter. And when it's
the first filter parameter the Qtime goes up
OK, something is not right here. What are
your autocommit settings? What you pasted
above looks like you're looking at a searcher that
has _just_ opened, which would mean either
1> you just had a hard commit with openSearcher=false happen
or
2> you just had a soft commit happen
In either case, the
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 defau
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
wrote:
: That did the trick Ahmet. The first response was around 200ms, but the
: subsequent queries were around 2-5ms.
Are
: 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 t
That did the trick Ahmet. The first response was around 200ms, but the
subsequent queries were around 2-5ms.
I tried this
&q=UserID:AC10263A-E28B-99F9-0012-AAA42DDD9336
&fq={!cache=false cost=100}Status:Booked
&fq={!cache=false cost=50}ClientID:4
&fq={!cache=false cost=50}[NOW/DAY TO NOW/DAY+1YE
Hi,
Did you try with non-cached filter quries before?
cached Filter queries are useful when they are re-used. How often do you commit?
I thought that we can do something if we disable cache filter queries and
manipulate their execution order with cost parameter.
What happens with this :
&q=User
Ahmet, I have tried filter queries before to fine tune query performance.
However, whenever we use filter queries the response time goes up and
remains there. With above change, the response time was consistently
around 4-5 secs. We are using the default cache settings.
Is there any settings I
Hi,
Since your range query has NOW in it, it won't be cached meaningfully.
http://solr.pl/en/2012/03/05/use-of-cachefalse-and-cost-parameters/
This is untested but can you try this?
&q=UserID:AC10263A-E28B-99F9-0012-AAA42DDD9336
&fq=Status:Booked
&fq=ClientID:4
&fq={!cache=false cost=150}StartDa
I am working with date range query that is not giving me faster response
times. After modifying date range construct after reading several forums,
response time now is around 200ms, down from 2-3secs.
However, I was wondering if there still some way to improve upon it as
queries without date rang
12 matches
Mail list logo
