lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Re: &fq degrades qtime in a 20million doc collection
Date Thu, 14 Jan 2016 01:10:49 GMT
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?


On Wed, Jan 13, 2016 at 4:27 PM, Anria B. <> 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:
> Sent from the Solr - User mailing list archive at

View raw message