Thanks a lot, your statement makes me feel better :-) It "feels" like this behavior showed up after changing to docValues for sorting, because before the 99 percentile for qtime was at 550ms average and 1.4 seconds at max.
So my assumption is that the inverted index on the sort fields (when _not_ using docValues) helps here with the disadvantage of using a lot of heap :-( Do you think an all_parameters -> complete_response cache is possible? It could be initialized right before or during warmup and would not take to much memory. Regards Bernd Am 06.08.2015 um 13:38 schrieb Toke Eskildsen: > On Thu, 2015-08-06 at 13:00 +0200, Bernd Fehling wrote: >> Single Index Solr 4.10.4, optimized Index, 76M docs, 235GB index size. >> >> I was analysing my solr logs and it turned out that I have some queries >> which are above 30 seconds qtime while normally the qtime is below 1 second. >> Looking closer about the queries it turned out that this is for >> MatchAllDocsQuery(*:*). >> Next was to turn debugQuery on and see where the bottleneck is. >> The result was that the facetting is consuming most of the qtime. >> >> So the question is, are facets or is facetting not cached? > > As far as I know it is not. 35 seconds for a match-all faceting sounds > fairly on par with what we are seeing (250M docs, 900GB shard). > > Of course response time is very depending on the field itself. If you > have very few unique values in your facet field(s), you might try > facet.method=enum. If that is not the case, your best bet would probably > be to cache the match-all outside of Solr. > >> My assumption is that the queryResultCache is catching such a >> MatchAllDocsQuery(*:*). > > It only stores the docIDs. > > I don't know why there is is no all_parameters -> complete_response > cache in Solr. > > - Toke Eskildsen, State and University Library, Denmark > >
