Hi Erick We do the DIH job from the DB and committed frequently.It takes a long time to autowarm the filterCaches after commit or soft commit happened when setting the autowarmcount=1024,which I do think is small enough. So It comes up an idea that whether it could directly pass the reference of the caches over to the new caches so that the autowarm processing will take much fewer time .
2014-07-28 2:30 GMT+08:00 Erick Erickson <erickerick...@gmail.com>: > Why do you think you _need_ to autowarm the entire cache? It > is, after all, an LRU cache, the theory being that the most recent > queries are most likely to be reused. > > Personally I'd run some tests on using small autowarm counts > before getting at all mixed up in some complex scheme that > may not be useful at all. Say an autowarm count of 16. Then > measure using that, then say 32 then... Insure you have a real > problem before worrying about a solution! ;) > > Best, > Erick > > > On Fri, Jul 25, 2014 at 6:45 AM, Shawn Heisey <s...@elyograg.org> wrote: > > > On 7/24/2014 8:45 PM, YouPeng Yang wrote: > > > To Matt > > > > > > Thank you,your opinion is very valuable ,So I have checked the source > > > codes about how the cache warming up. It seems to just put items of > the > > > old caches into the new caches. > > > I will pull Mark Miller into this discussion.He is the one of the > > > developer of the Solr whom I had contacted with. > > > > > > To Mark Miller > > > > > > Would you please check out what we are discussing in the last two > > > posts.I need your help. > > > > Matt is completely right. Any commit can drastically change the Lucene > > document id numbers. It would be too expensive to determine which > > numbers haven't changed. That means Solr must throw away all cache > > information on commit. > > > > Two of Solr's caches support autowarming. Those caches use queries as > > keys and results as values. Autowarming works by re-executing the top N > > queries (keys) in the old cache to obtain fresh Lucene document id > > numbers (values). The cache code does take *keys* from the old cache > > for the new cache, but not *values*. I'm very sure about this, as I > > wrote the current (and not terribly good) LFUCache. > > > > Thanks, > > Shawn > > > > >
