Shamik:
You're right, the use of NOW shouldn't be making that much of a difference
between versions. FYI, though, here's a way to use NOW and re-use fq
clauses:
http://searchhub.org/2012/02/23/date-math-now-and-filter-queries/
It may well be this setting:
1000
Every second (assuming
Hi,
What happens if you have just 1 shard - no distributed search, like
before? SPM for Solr or any other monitoring tool that captures OS and
Solr metrics should help you find the source of the problem faster.
Is disk IO the same? utilization of caches? JVM version, heap, etc.?
CPU usage? network
I tried commenting out NOW in bq, but didn't make any difference in the
performance. I do see minor entry in the queryfiltercache rate which is a
meager 0.02.
I'm really struggling to figure out the bottleneck, any known pain points I
should be checking ?
--
View this message in context:
http
Thanks Primoz, I was suspecting that too. But then, its hard to imagine that
query cache is only contributing to the big performance hit. The setting
applies to the old configuration, and it works pretty well even with the
query cache low hit rate.
--
View this message in context:
http://lucene
Query result cache hit might be low due to using NOW in bf. NOW is always
translated to current time and that of course changes from ms to ms... :)
Primoz
From: Shamik Bandopadhyay
To: solr-user@lucene.apache.org
Date: 17.10.2013 00:14
Subject:SolrCloud Performance Issue
Hi
