It's quite surprising that you're getting this kind of query degradation by adding an "fq" clause unless something's really out of whack on the setup. How much memory are you giving the JVM? Are you autowarming? Are you indexing while this is going on, and if what are your commit parameters? If you add &debug=true to your query, one of the returned sections will be "timings" for the various components of a query measured in milliseconds. Occasionally there will be surprises in there.
What are you measuring when you say it takes seconds? The time to render the result page or are you looking at the QTime parameter of the return packet? Best, Erick On Wed, Jan 13, 2016 at 4:27 PM, Anria B. <anria_o...@yahoo.com> wrote: > hi Shawn > > Thanks for the quick answer. As for the q=*, we also saw similar results > in our testing when doing things like > > q=somefield:qval > &fq=otherfield:fqval > > Which makes a pure Lucene query. I simplified things somewhat since our > results were always that as numFound got large, the query time degraded as > soon as we added any &fq in the mix. > > We also saw similar results for queries like > > q=query stuff > &defType=edismax > &df=afield > &qf=afield bfield cfield > > > So the query structure was not what created the 3-7 second query time, it > was always a correlation between is &fq in the query, and what is the > numFound. We've run numerous load tests for bringing in good query with fq > values in the "newSearcher", caches on, caches off ... this same > phenomenon persisted. > > As for Tomcat, it's an easy enough test to run it in Jetty. We will sure > try that! GC we've had default and G1 setups. > > Thanks for giving us something to think about > > Anria > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/fq-degrades-qtime-in-a-20million-doc-collection-tp4250567p4250600.html > Sent from the Solr - User mailing list archive at Nabble.com.
