Hi Kevin,
Right, it's the very frequent commits, most likely. Change commits
to, say, every 60 or 120 seconds and compare the performance. I think
you guys use SPM, so check the Cache graphs (hit % specifically)
before and after the above change.
Otis
--
Search Analytics - http://sematext.com/s
On 10/8/2012 4:09 PM, kevinlieb wrote:
Thanks for all the replies.
I oversimplified the problem for the purposes of making my post small and
concise. I am really trying to find the counts of documents by a list of 10
different authors that match those keywords. Of course on looking up a
single
Thanks for all the replies.
I oversimplified the problem for the purposes of making my post small and
concise. I am really trying to find the counts of documents by a list of 10
different authors that match those keywords. Of course on looking up a
single author there is no reason to do a facet
: a small time slice. However even if I take the time slice query out it
: takes the same amount of time, so it seems to be searching the entire data
: set.
a) you might try using facet.method=enum - in some special cases it may be
faster then the default (facet.method=fc).
: I am trying to fi
Facets are only really useful if you want the counts for multiple values (e.g.,
"eldudearino", "ladudearina"). I'd suggest just leaving all the facet
parameters off of that query - the numFound that is returned should give you
what you want.
The slowness may be due to the facet cache needing to
Faceting at that scale takes time to "warm up". If you've got your caches and
such configured appropriately, then successive searches will be very fast,
however you'll still need to do the cache warming (depends on the faceting
implementation you're using, in this case you're probably using the
