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: <autoSoftCommit> <maxTime>1000</maxTime> </autoSoftCommit> Every second (assuming you're indexing), you're throwing away all your top-level caches and executing any autowarm queries etc. And if you _don't_ have any autowarming queries, you may not be filling caches, an expensive process. Try lengthening that out to, say, a minute (60000) or even longer and see if that makes a difference. If that's the culprit, you at least have a place to start. If that's not it, it's also possible you're seeing decompression. How many documents are you returning and how big are they? There's some anecdotal comments that the default stored field decompression for either a large number of doc or very large docs may be playing a role here. Try setting fl=id (don't return any stored fields). If that is faster, this might be your problem. queryResultCache is often not very high re: hit ratio. It's usually used for paging, so if your users aren't hitting the "next" page you may not hit many. Best, Erick On Sat, Oct 19, 2013 at 4:12 AM, Otis Gospodnetic < otis.gospodne...@gmail.com> wrote: > 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'd look at each of these things side by side and > look for big differences. > > Otis > -- > Solr & ElasticSearch Support -- http://sematext.com/ > SOLR Performance Monitoring -- http://sematext.com/spm > > > > On Fri, Oct 18, 2013 at 1:38 AM, shamik <sham...@gmail.com> wrote: > > 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://lucene.472066.n3.nabble.com/SolrCloud-Performance-Issue-tp4095971p4096277.html > > Sent from the Solr - User mailing list archive at Nabble.com. >
