You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Bernd Fehling <be...@uni-bielefeld.de> on 2015/08/06 13:00:47 UTC
are facets or MatchAllDocsQuery not cached?
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?
Even after sending the query several times in a row I don't get below 35 seconds qtime.
Is this normal for a MatchAllDocsQuery(*:*)?
My assumption is that the queryResultCache is catching such a MatchAllDocsQuery(*:*).
Am I wrong?
debug":{
"rawquerystring":"*:*",
"querystring":"*:*",
"parsedquery":"(+MatchAllDocsQuery(*:*))/no_coord",
"parsedquery_toString":"+*:*",
"QParser":"ExtendedDismaxQParser",
"altquerystring":null,
"boost_queries":null,
"parsed_boost_queries":[],
"boostfuncs":null,
...
"timing":{
"time":37429.0,
"prepare":{
"time":0.0,
"queryfilter":{
"time":0.0},
"query":{
"time":0.0},
"facet":{
"time":0.0},
"mlt":{
"time":0.0},
"highlight":{
"time":0.0},
"stats":{
"time":0.0},
"expand":{
"time":0.0},
"debug":{
"time":0.0}},
"process":{
"time":37429.0,
"queryfilter":{
"time":0.0},
"query":{
"time":2310.0},
"facet":{
"time":35117.0},
"mlt":{
"time":0.0},
"highlight":{
"time":0.0},
"stats":{
"time":0.0},
"expand":{
"time":0.0},
"debug":{
"time":2.0}}}}}
Regards
Bernd
Re: are facets or MatchAllDocsQuery not cached?
Posted by Upayavira <uv...@odoko.co.uk>.
Typically such performance issues with faceting are to do with the time
spend uninverting the index before calculating the facet counts.
If you indexed the fields with docValues enabled, perhaps you could then
use them for faceting, which might improve performance.
If you are using a non-docValues field, and the second query is faster,
then you could add the query to your static warming, look for
newSearcher in your solrconfig.xml. That will execute your query,
warming the caches used by faceting, before a new searcher is made
available for searches.
Upayavira
On Thu, Aug 6, 2015, at 12:38 PM, Toke Eskildsen wrote:
> 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
>
>
Re: are facets or MatchAllDocsQuery not cached?
Posted by Upayavira <uv...@odoko.co.uk>.
On Thu, Aug 6, 2015, at 06:56 PM, Toke Eskildsen wrote:
> Upayavira <uv...@odoko.co.uk> wrote:
> > Also, attempting to facet across a large number of docs is going to take
> > some time. Perhaps you might gain some performance benefit by sharding
> > your index?
>
> One should be aware that distributed faceting on String fields has a
> non-trivial overhead: It is a two-phase system, where the first phase is
> a bit heavier than a non-distributed faceting call and the second phase
> varies (depending on corpus and query) between being lighter and even
> heavier.
>
> If faceting performance is the problem, it is quite possible to end up
> with worse overall performance by changing from a single-shard setup to a
> multi-shard one. As always, measure.
Depending upon the cardinality of your facets, for sure. As you say,
measure.
Upayavira
Re: are facets or MatchAllDocsQuery not cached?
Posted by Toke Eskildsen <te...@statsbiblioteket.dk>.
Upayavira <uv...@odoko.co.uk> wrote:
> Also, attempting to facet across a large number of docs is going to take
> some time. Perhaps you might gain some performance benefit by sharding
> your index?
One should be aware that distributed faceting on String fields has a non-trivial overhead: It is a two-phase system, where the first phase is a bit heavier than a non-distributed faceting call and the second phase varies (depending on corpus and query) between being lighter and even heavier.
If faceting performance is the problem, it is quite possible to end up with worse overall performance by changing from a single-shard setup to a multi-shard one. As always, measure.
- Toke Eskildsen
Re: are facets or MatchAllDocsQuery not cached?
Posted by Upayavira <uv...@odoko.co.uk>.
Also, attempting to facet across a large number of docs is going to take
some time. Perhaps you might gain some performance benefit by sharding
your index?
Upayavira
On Thu, Aug 6, 2015, at 04:48 PM, Mikhail Khludnev wrote:
> On Thu, Aug 6, 2015 at 3:56 PM, Bernd Fehling <
> bernd.fehling@uni-bielefeld.de> wrote:
>
> >
> >
> > Am 06.08.2015 um 14:33 schrieb Upayavira:
> > > Typically such performance issues with faceting are to do with the time
> > > spend uninverting the index before calculating the facet counts.
> > >
> > > If you indexed the fields with docValues enabled, perhaps you could then
> > > use them for faceting, which might improve performance.
> >
> > Well, this is against my observations. When I used uninverted fields
> > without
> > docValues I had a much better 99 percentile qtime but a very high heap
> > consumption.
> > Now with docValues the heap usage went down, but the 99 percentile
> > qtime for MatchAllDocsQuery(*:*) went up to above 33 seconds.
> >
>
> Note about performance optimization for DocValues faceting in
> forthcoming
> 5.3
>
>
> >
> > >
> > > If you are using a non-docValues field, and the second query is faster,
> > > then you could add the query to your static warming, look for
> > > newSearcher in your solrconfig.xml. That will execute your query,
> > > warming the caches used by faceting, before a new searcher is made
> > > available for searches.
> >
> > The q=*.* with sorting and facetting is always the first query I'm doing
> > at static warming and it helped until switching to docValues :-(
> >
> > Bernd
> >
> > >
> > > Upayavira
> > >
> > > On Thu, Aug 6, 2015, at 12:38 PM, Toke Eskildsen wrote:
> > >> 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
> > >>
> > >>
> >
>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
> Principal Engineer,
> Grid Dynamics
>
> <http://www.griddynamics.com>
> <mk...@griddynamics.com>
Re: are facets or MatchAllDocsQuery not cached?
Posted by Mikhail Khludnev <mk...@griddynamics.com>.
On Thu, Aug 6, 2015 at 3:56 PM, Bernd Fehling <
bernd.fehling@uni-bielefeld.de> wrote:
>
>
> Am 06.08.2015 um 14:33 schrieb Upayavira:
> > Typically such performance issues with faceting are to do with the time
> > spend uninverting the index before calculating the facet counts.
> >
> > If you indexed the fields with docValues enabled, perhaps you could then
> > use them for faceting, which might improve performance.
>
> Well, this is against my observations. When I used uninverted fields
> without
> docValues I had a much better 99 percentile qtime but a very high heap
> consumption.
> Now with docValues the heap usage went down, but the 99 percentile
> qtime for MatchAllDocsQuery(*:*) went up to above 33 seconds.
>
Note about performance optimization for DocValues faceting in forthcoming
5.3
>
> >
> > If you are using a non-docValues field, and the second query is faster,
> > then you could add the query to your static warming, look for
> > newSearcher in your solrconfig.xml. That will execute your query,
> > warming the caches used by faceting, before a new searcher is made
> > available for searches.
>
> The q=*.* with sorting and facetting is always the first query I'm doing
> at static warming and it helped until switching to docValues :-(
>
> Bernd
>
> >
> > Upayavira
> >
> > On Thu, Aug 6, 2015, at 12:38 PM, Toke Eskildsen wrote:
> >> 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
> >>
> >>
>
--
Sincerely yours
Mikhail Khludnev
Principal Engineer,
Grid Dynamics
<http://www.griddynamics.com>
<mk...@griddynamics.com>
Re: are facets or MatchAllDocsQuery not cached?
Posted by Bernd Fehling <be...@uni-bielefeld.de>.
Hi Mikhail, you are my hero!
I added your patch to 4.10.4, recompiled, tested and pushed from testing stage
to online system. What a difference!
Right after restart the performance increase for faceting is times 10.
Qtime for MatchAllDocsQuery(*:*) and docValues and faceting went down from
around 35 seconds to 3.5 seconds for faceting.
After 1 hour under load the qtime is somewhere around 15 percent performance
increase for faceting.
This patch is a must have!
Regards
Bernd
Am 07.08.2015 um 08:45 schrieb Bernd Fehling:
>
>
> Am 06.08.2015 um 17:48 schrieb Mikhail Khludnev:
>> On Thu, Aug 6, 2015 at 3:56 PM, Bernd Fehling <
>> bernd.fehling@uni-bielefeld.de> wrote:
>>
>>>
>>>
>>> Am 06.08.2015 um 14:33 schrieb Upayavira:
>>>> Typically such performance issues with faceting are to do with the time
>>>> spend uninverting the index before calculating the facet counts.
>>>>
>>>> If you indexed the fields with docValues enabled, perhaps you could then
>>>> use them for faceting, which might improve performance.
>>>
>>> Well, this is against my observations. When I used uninverted fields
>>> without
>>> docValues I had a much better 99 percentile qtime but a very high heap
>>> consumption.
>>> Now with docValues the heap usage went down, but the 99 percentile
>>> qtime for MatchAllDocsQuery(*:*) went up to above 33 seconds.
>>>
>>
>> Note about performance optimization for DocValues faceting in forthcoming
>> 5.3
>>
>
> Thanks for pointing this out.
> Do you think that it is possible to merge this patch into 4.10.4 or
> is 5.3 to far away from 4.10.4 in this area of code?
>
>
>>
>>>
>>>>
>>>> If you are using a non-docValues field, and the second query is faster,
>>>> then you could add the query to your static warming, look for
>>>> newSearcher in your solrconfig.xml. That will execute your query,
>>>> warming the caches used by faceting, before a new searcher is made
>>>> available for searches.
>>>
>>> The q=*.* with sorting and facetting is always the first query I'm doing
>>> at static warming and it helped until switching to docValues :-(
>>>
>>> Bernd
>>>
>>>>
>>>> Upayavira
>>>>
>>>> On Thu, Aug 6, 2015, at 12:38 PM, Toke Eskildsen wrote:
>>>>> 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
>>>>>
>>>>>
>>>
>
--
*************************************************************
Bernd Fehling Bielefeld University Library
Dipl.-Inform. (FH) LibTec - Library Technology
Universitätsstr. 25 and Knowledge Management
33615 Bielefeld
Tel. +49 521 106-4060 bernd.fehling(at)uni-bielefeld.de
BASE - Bielefeld Academic Search Engine - www.base-search.net
*************************************************************
Re: are facets or MatchAllDocsQuery not cached?
Posted by Bernd Fehling <be...@uni-bielefeld.de>.
Am 06.08.2015 um 17:48 schrieb Mikhail Khludnev:
> On Thu, Aug 6, 2015 at 3:56 PM, Bernd Fehling <
> bernd.fehling@uni-bielefeld.de> wrote:
>
>>
>>
>> Am 06.08.2015 um 14:33 schrieb Upayavira:
>>> Typically such performance issues with faceting are to do with the time
>>> spend uninverting the index before calculating the facet counts.
>>>
>>> If you indexed the fields with docValues enabled, perhaps you could then
>>> use them for faceting, which might improve performance.
>>
>> Well, this is against my observations. When I used uninverted fields
>> without
>> docValues I had a much better 99 percentile qtime but a very high heap
>> consumption.
>> Now with docValues the heap usage went down, but the 99 percentile
>> qtime for MatchAllDocsQuery(*:*) went up to above 33 seconds.
>>
>
> Note about performance optimization for DocValues faceting in forthcoming
> 5.3
>
Thanks for pointing this out.
Do you think that it is possible to merge this patch into 4.10.4 or
is 5.3 to far away from 4.10.4 in this area of code?
>
>>
>>>
>>> If you are using a non-docValues field, and the second query is faster,
>>> then you could add the query to your static warming, look for
>>> newSearcher in your solrconfig.xml. That will execute your query,
>>> warming the caches used by faceting, before a new searcher is made
>>> available for searches.
>>
>> The q=*.* with sorting and facetting is always the first query I'm doing
>> at static warming and it helped until switching to docValues :-(
>>
>> Bernd
>>
>>>
>>> Upayavira
>>>
>>> On Thu, Aug 6, 2015, at 12:38 PM, Toke Eskildsen wrote:
>>>> 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
>>>>
>>>>
>>
Re: are facets or MatchAllDocsQuery not cached?
Posted by Bernd Fehling <be...@uni-bielefeld.de>.
Am 06.08.2015 um 14:33 schrieb Upayavira:
> Typically such performance issues with faceting are to do with the time
> spend uninverting the index before calculating the facet counts.
>
> If you indexed the fields with docValues enabled, perhaps you could then
> use them for faceting, which might improve performance.
Well, this is against my observations. When I used uninverted fields without
docValues I had a much better 99 percentile qtime but a very high heap consumption.
Now with docValues the heap usage went down, but the 99 percentile
qtime for MatchAllDocsQuery(*:*) went up to above 33 seconds.
>
> If you are using a non-docValues field, and the second query is faster,
> then you could add the query to your static warming, look for
> newSearcher in your solrconfig.xml. That will execute your query,
> warming the caches used by faceting, before a new searcher is made
> available for searches.
The q=*.* with sorting and facetting is always the first query I'm doing
at static warming and it helped until switching to docValues :-(
Bernd
>
> Upayavira
>
> On Thu, Aug 6, 2015, at 12:38 PM, Toke Eskildsen wrote:
>> 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
>>
>>
Re: are facets or MatchAllDocsQuery not cached?
Posted by Toke Eskildsen <te...@statsbiblioteket.dk>.
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
Re: are facets or MatchAllDocsQuery not cached?
Posted by Toke Eskildsen <te...@statsbiblioteket.dk>.
On Thu, 2015-08-06 at 14:32 +0200, Bernd Fehling wrote:
> 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.
DocValues have faster startup but comes with a constant performance cost
as they have to be fetched through the memory map. Judged from what
people are observing & sharing, that cost is "small".
Field faceting (docValues or not) takes more time for larger result
sets. If your queries are anywhere like ours, the vast majority of them
will hit a fairly small subset of your whole corpus. Your 99% might
contain only queries with hit count < 10% of your total document count
(hand waving a lot here).
When we are talking faceting, I find generating a plot from the
production log, with hit count on x and response time on y, very
illuminating.
> 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 :-(
Yes. But I highly doubt that it explains a factor 30 in speed. More like
a factor 2.
> 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.
Sorry, I don't know much of the mechanics of handlers in Solr and cannot
say how the in-theory-simple caching would fit.
- Toke Eskildsen, State and University Library, Denmark
Re: are facets or MatchAllDocsQuery not cached?
Posted by Erik Hatcher <er...@gmail.com>.
> 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.
This is along the lines of Solr’s 304 capabilities. See <https://cwiki.apache.org/confluence/display/solr/RequestDispatcher+in+SolrConfig#RequestDispatcherinSolrConfig-httpCachingElement <https://cwiki.apache.org/confluence/display/solr/RequestDispatcher+in+SolrConfig#RequestDispatcherinSolrConfig-httpCachingElement>>
Hooking some kind of caching layer in front of Solr that can leverage the 304 responses is something I’ve heard of folks doing.
—
Erik Hatcher, Senior Solutions Architect
http://www.lucidworks.com <http://www.lucidworks.com/>
> On Aug 6, 2015, at 8:32 AM, Bernd Fehling <be...@uni-bielefeld.de> wrote:
>
> 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
>>
>>
Re: are facets or MatchAllDocsQuery not cached?
Posted by Bernd Fehling <be...@uni-bielefeld.de>.
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
>
>