300 ms seems pretty good for 200 million documents. Is that average? Median? 95th percentile?
Why are you sure it is because the huge number of hits? That would be unusual. The size of the posting lists is a more common cause. Why do you think it is caused by tf.idf? That should be faster than BM25. Does host have enough RAM to hold most or all of the index in file buffers? What are the hit rates on your caches? Are you using fuzzy matches? N-gram prefix matching? Phrase matching? Shingles? What version of Java are you running? What garbage collector? wunder Walter Underwood wun...@wunderwood.org <mailto:wun...@wunderwood.org> http://observer.wunderwood.org/ (my blog) > On Feb 21, 2017, at 10:42 AM, Doug Turnbull > <dturnb...@opensourceconnections.com > <mailto:dturnb...@opensourceconnections.com>> wrote: > > With that many documents, why not start with an AND search and reissue an > OR query if there's no results? My strategy is to prefer an AND for large > collections (or a higher mm than 1) and prefer closer to an OR for smaller > collections. > > -Doug > > On Tue, Feb 21, 2017 at 1:39 PM Fuad Efendi <f...@efendi.ca > <mailto:f...@efendi.ca>> wrote: > >> Thank you Ahmet, I will try it; sounds reasonable >> >> >> From: Ahmet Arslan <iori...@yahoo.com.invalid >> <mailto:iori...@yahoo.com.invalid>> <iori...@yahoo.com.invalid >> <mailto:iori...@yahoo.com.invalid>> >> Reply: solr-user@lucene.apache.org <mailto:solr-user@lucene.apache.org> >> <solr-user@lucene.apache.org <mailto:solr-user@lucene.apache.org>> >> <solr-user@lucene.apache.org <mailto:solr-user@lucene.apache.org>>, Ahmet >> Arslan <iori...@yahoo.com <mailto:iori...@yahoo.com>> >> <iori...@yahoo.com <mailto:iori...@yahoo.com>> >> Date: February 21, 2017 at 3:02:11 AM >> To: solr-user@lucene.apache.org <mailto:solr-user@lucene.apache.org> >> <solr-user@lucene.apache.org <mailto:solr-user@lucene.apache.org>> >> <solr-user@lucene.apache.org <mailto:solr-user@lucene.apache.org>> >> Subject: Re: CPU Intensive Scoring Alternatives >> >> Hi, >> >> New default similarity is BM25. >> May be explicitly set similarity to tf-idf and see how it goes? >> >> Ahmet >> >> >> On Tuesday, February 21, 2017 4:28 AM, Fuad Efendi <f...@efendi.ca >> <mailto:f...@efendi.ca>> wrote: >> Hello, >> >> >> Default TF-IDF performs poorly with the indexed 200 millions documents. >> Query "Michael Jackson" may run 300ms, and "Michael The Jackson" over 3 >> seconds. eDisMax. Because default operator "OR" and stopword "The" we have >> 50-70 millions documents as a query result, and scoring is CPU intensive. >> What to do? Our typical queries return over million documents, and response >> times of simple queries ranges from 50 milliseconds to 5-10 seconds >> depending on result set. >> >> This was just an exaggerated example with stopword “the”, but even simplest >> query “Michael Jackson” runs 300ms instead of 3ms just because huge number >> of hits and TF-IDF calculations. Solr 6.3. >> >> >> Thanks, >> >> -- >> >> Fuad Efendi >> >> (416) 993-2060 >> >> http://www.tokenizer.ca <http://www.tokenizer.ca/> >> Search Relevancy, Recommender Systems >>
