I recall a couple of previous discussions regarding some sort of filter/field cache change in Lucene where they removed what had been an optimization for Solr.
-- Jack Krupansky On Wed, Jan 13, 2016 at 8:10 PM, Erick Erickson <erickerick...@gmail.com> wrote: > 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. >
