lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Re: To warm the whole cache of Solr other than the only autowarmcount
Date Sun, 27 Jul 2014 18:30:35 GMT
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! ;)


On Fri, Jul 25, 2014 at 6:45 AM, Shawn Heisey <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message