On Mon, October 21, 2013 10:04 AM, Toke Eskildsen wrote:
>On Fri, 2013-10-18 at 18:30 +0200, Lemke, Michael SZ/HZA-ZSW wrote:
>> Toke Eskildsen wrote:
>> > Unfortunately the enum-solution is normally quite slow when there
>> > are enough unique values to trigger the "too many > values"-exception.
>> > [...]
>>
>> [...] And yes, the fc method was terribly slow in a case where it did
>> work. Something like 20 minutes whereas enum returned within a few
>> seconds.
>
>Err.. What? That sounds _very_ strange. You have millions of unique
>values so fc should be a lot faster than enum, not the other way around.
>
>I assume the 20 minutes was for the first call. How fast does subsequent
>calls return for fc?
QTime enum:
1st call: 1200
subsequent calls: 200
QTime fc:
never returns, webserver restarts itself after 30 min with 100% CPU load
This is on the test system, the production system managed to return with
"... Too many values for UnInvertedField faceting ...".
However, I also have different faceting queries I played with today.
One complete example:
q=ottomotor&facet.field=CONTENT&facet=true&facet.prefix=&facet.limit=10&facet.mincount=1&facet.method=enum&rows=0
These are the results, all with facet.method=enum (fc doesn't work). They
were executed in the sequence shown on an otherwise unused server:
QTime=41205 facet.prefix= q=frequent_word
numFound=44532
Same query repeated:
QTime=225810 facet.prefix= q=ottomotor
numFound=909
QTime=199839 facet.prefix= q=ottomotor
numFound=909
QTime=0 facet.prefix= q=ottomotor jkdhwjfh
numFound=0
QTime=0 facet.prefix= q=jkdhwjfh
numFound=0
QTime=185948 facet.prefix= q=ottomotor
numFound=909
QTime=3344 facet.prefix=d q=ottomotor
numFound=909
QTime=3078 facet.prefix=d q=ottomotor
numFound=909
QTime=3141 facet.prefix=d q=ottomotor
numFound=909
The response time is obviously not dependent on the number of documents found.
Caching doesn't kick in either.
>
>
>Maybe you could provide some approximate numbers?
I'll try, see below. Thanks for asking and having a closer look.
>
>- Documents in your index
13,434,414
>- Unique values in the CONTENT field
Not sure how to get this. In luke I find
21,797,514 term count CONTENT
Is that what you mean?
>- Hits are returned from a typical query
Hm, that can be anything between 0 and 40,000 or more.
Or do you mean from the facets? Or do my tests above
answer it?
>- Xmx
The maximum the system allows me to get: 1612m
Maybe I have a hopelessly under-dimensioned server for this sort of things?
Thanks a lot for your help,
Michael
