jerome.dup...@bnf.fr [jerome.dup...@bnf.fr] wrote: [1 thread = 15 seconds, ∞ threads = 2 seconds]
> The "slow" request corresponds to our website search query. It for our > book catalog: some facets are for type of documents, author, title > subjets, location of the book, dates... > In this request we have now 35 facets. Okay, that might by itself be a little problematic as Solr treats all facets separately. That also explains the large speed-up from threading. > About unique value, for the "slow" query: > 1 facet goes up to 4M unique values (authors), > 1 facet has 250.000 uniques values > 1 have 50000 > 1 have 6700 > 4 have between 300 and 1000 > 5 have between 100 and 160 > 16 have less than 65 Guessing that a slow query is one that matches a lot of documents (so that the document IDs are represented internally as a bitmap), each facet means that 12M bits are checked and several million of those (the hits) are looked up in doc->term_ordinal tables, in order to update the facet counters. With 35 facets, this means checking 400M bits, doing maybe 100M lookups and the same amount of updates. If you could collapse some of the facets by indexing their values in a common field, it would help a lot. >> Toke: Or you could try Sparse Faceting I take that somewhat back: Sparse faceting would help with your authors field, and maybe the 250.000 one, but your main problem seems to be the sheer number of facet fields. - Toke Eskildsen
