On Thu, Dec 5, 2013 at 4:49 PM, Yonik Seeley <yo...@heliosearch.com> wrote:
> On Thu, Dec 5, 2013 at 7:39 AM, Dmitry Kan <solrexp...@gmail.com> wrote: > > Thanks Erick! > > To be sure we are using cost 101 and no cache. It seems to affect on > > searches as we expected. > > > > Basically with cache on we see more "fat" spikes around commit points, as > > cache is getting flushed (we don't rerun too many entries from old > cache). > > But when the post-filtering is involved, those spikes are thinner, but > the > > rest of the queries take about 2 seconds longer (our queries are pretty > > heavy duty stuff). > > > > So the post-filtering gives an option of making trade-offs between query > > times for all users during normal execution and query times during > commits. > > To rephrase we have 2 options: > > > > 1. Make all searches somewhat slower for all users and avoid really slow > > searches around commit points: post-filtering option > > > > OR > > > > 2. Make majority of searches really fast, but around commit points really > > slow: normal with cache option > > OR > > 3. Use warming queries or auto-warming of caches to make all searches fast > but the commits themselves slow. > > thanks Yonik. This is indeeed what we have tried originally. But, as I have briefly described on the Dublin's Stump the Chump, auto-warming is way too long and does not complete within up to an hour. So the next commit kicks in and so on. So we opted for an external automatic warming. > -Yonik > http://heliosearch.com -- making solr shine > -- Dmitry Blog: http://dmitrykan.blogspot.com Twitter: twitter.com/dmitrykan
