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.
